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1.0  INTRODUCTION 


This  chapter  explains  the  purpose  of  the  convention,  and  the  scope 
of  the  guidance  and  provides  an  explanation  of  how  to  use  the 
convention. 


1.1  PURPOSE  OF  THE  CONVENTION 

The  convention  provides  general  guidance  on  the  implementation 
of  American  National  Standards  Institute  (ANSI)  Accredited  Stand¬ 
ards  Committee  (ASC)  X12  electronic  dau  interchange  (EDI) 
standards  within  automated  information  systems  (AIS)  and  on 
information  interchange  procedures  that  require  the  collection, 
reporting,  and/or  exchange  of  dau  needed  to  perform  defense 
missions. 


1.2  SCOPE 

The  guidance  presented  here  may  be  used  by  organizational  ele¬ 
ments  of  the  DoD  community  and  by  non-DoD  organizations  that 
exchange  dau  with  the  DoD  community  in  the  course  of  their 
business  relationships. 

The  DoD  community  encompasses  the  Miliuiy  Services,  Organiza¬ 
tions  of  the  Joint  Chiefs  of  Staff,  Unified  and  Specified  Commands, 
Office  of  the  Secretary  of  Defense,  and  the  Defense  agencies.  (That 
community  is  collectively  refeired  to  as  the  DoD  Componenu). 

Non-DoD  organizations  include  (a)  non-Govemment  organiza¬ 
tions,  both  commercial  and  nonprofit;  (b)  Federal  agencies  of  the 
United  Sutes  Government  other  than  DoD;  (c)  local  and  sute 
governments;  (d)  foreign  national  governments;  and  (e)  interna¬ 
tional  government  organizations. 

The  draft  convention  published  in  this  document  is  for  trial  use 
and  comment.  DoD  Components  must  submit  to  the  Office  of  the 
Under  Secretary  of  Defense  (Acquisition  and  Technology),  Com¬ 
puter-aided  Acquisition  and  Logistics  Support  and  Electronic  Dau 
Interchange  [OUSD  (A  &  T)  CALS/EDI]  their  dau  requirements 
that  are  not  covered  in  this  convention  as  soon  as  possible,  as 
indicated  in  Chapter  2.0,  Section  2.1. 

13  RESPONSIBLE  ENTITY 

{Reserved} 

1.4  HOW  TO  USE  THE  IMPLEMENTATION 
CONVENTION 

The  main  topics  and  structures  of  this  document  conform  to  the 
EDI  Implementation  Reference  Manual  Guidelines  document  that 
was  developed  by  a  Usk  group  of  the  subcommittee  on  education 
and  implemenution  of  the  ASC  X12.  The  purpose  of  having 
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agreed-upon  topics  and  structure  is  to  faciliute  reference  by  the 
many  industry  and  DoD  personnel  who  are  involved  in  implement¬ 
ing  the  uniform  standards  for  electronic  interchange  of  business 
transactions. 

1.4.1  Conventions,  Standards,  and  Guidelines 

The  terms  conventions,  sundards,  and  guidelines  are  used 
throughout  this  document  and  are  defined  as  follows: 

•  Conventions  are  the  common  practices  and/or  interpretations 
of  the  use  of  ASC  X12  standards.  Conventions  define  what  is 
included  in  a  specific  implementation  of  an  ASC  X 1 2  standard. 

•  Standards  are  the  technical  documentation  approved  by 
ASC  XI 2;  specifically,  transaction  sets,  segments,  data  ele¬ 
ments,  code  sets,  and  interchange  control  structure.  Standards 
provide  the  structure  for  each  ASC  X12  document. 

•  Guidelines  are  instructions  on  the  use  of  EDI.  They  provide 
additional  information  to  assist  in  conducting  EDI.  Guidelines 
are  intended  to  provide  assistance  and  should  not  be  your  sole 
source  of  information. 

1 .4.1 .1  Who  Develops  the  Conventions? 

Conventions  result  from  a  joint  effort  by  business,  technical,  and 
EDI  ASC  X12  standards  experts.  The  business  dau  requirement 
is  defined,  a  transaction  set  is  selected,  and  the  data  requirement 
is  then  identified  with  data  elements  in  the  transaction  set.  A 
convention  is  usually  developed  before  any  conqiuter  EDI  systems 
developrmnt  work  and  serves  as  a  design  document  when  the 
development  process  begins. 

1.4.1. 2  Why  Use  a  Convontion? 

To  create  an  ASC  X12  transaction,  a  user  must  know  the  data 
requirements,  understand  the  ASC  XI 2  standard,  and  be  able  to 
use  that  information  to  develop  an  interface  program  between  the 
computer  application  and  the  ASC  X12  translator.  The  necessary 
information  to  perform  that  task  is  contained  in  the  convention 
document  Users  who  follow  the  convention  will  create  a  transac¬ 
tion  set  that  all  DoD  users  understand. 

1 .4.1 .3  Who  Nsods  a  Convention? 

System  analysts  and  application  programmers  who  plan  to  create 
or  read  ASC  X12  transactions  use  a  convention  to  aid  in  interface 
software  design.  The  convention  will  help  the  programmer  and 
analyst  identify  where  their  application  data  requirement  should  be 
carried  in  an  ASC  X12  transaction  set. 

1. 4.4.4  Can  I  Develop  a  Convention? 

Conventions  already  exist  for  some  of  the  most  common  business 
practices.  Copies  of  existing  conventions  can  be  acquired  through 
your  organization’s  EDI  coordinator  at  the  start  of  an  EDI  project. 
If  you  find  no  conventions  for  the  business  practice  you  are  about 
to  implement,  your  EDI  coordinator  should  contact  the  CALS 
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Evaluation  and  Integration  Office.  See  Chapter  2.0,  Maintenance, 
Section  2.1  for  the  point  of  contact. 

1.4.2  Documentation  of  Conventions 

Conventions  are  adopted  from,  and  are  intended  to  be  in  confor¬ 
mance  with.  ANSI  ASC  XI2  standards  or  ASC  X12  Draft  Stand¬ 
ards  for  Trial  Use  (DSTU). 

1. 4.2.1  Transaction  Set 

Figure  1.4-1  provides  an  example  cf  a  transaction  set  table.  The 
transaction  set  defines  information  of  business  or  strategic  sig¬ 
nificance  and  consists  of  a  transaction  set  header  segment,  one  or 
more  data  segments  in  a  specified  order,  and  a  transaction  set 
trailer  segment.  The  actual  ASC  X12  standard  as  it  appears  iu  the 
official  ASC  X12  standards  manual  is  presented  on  the  right  side 
of  the  page.  That  standard  also  includes  both  syntax  notes  and 
comments.  The  specific  DoD  usage  designator  is  presented  on  the 
left  side  of  the  page. 

The  designation  “N/U”  stands  for  “not  used”  and  appears  in  the 
left  column  if  DoD  does  not  use  the  specific  segment.  A  page 
number  will  appear  if  the  segment  is  used. 

1 .4.2.2  Transaction  Sat  Segment 

Figure  1.4-2  is  an  example  of  a  transaction  set  segment, 

DoD  usage  is  specified  on  the  left  side  of  the  page.  For  identifier 
(ID)-type  data  elements,  acceptable  code  values  are  listed  on  the 
right  side  of  the  page  under  the  definitions  of  the  element 

DoD  notes,  reflecting  bow  the  convention  is  to  be  used  appear  on 
the  right  side  of  the  page  at  the  segment  level  or  the  data  element 
level. 

The  following  definitions  are  for  use  in  interpreting  the  data 
element  requirement  designators  in  the  DoD-specific  segment 
directory  section  of  the  convention.  For  ASC  X12  usage,  see  the 
definitions  in  XI 2.6  Application  Control  Structure. 

•  Mandatory 

Mandatory  data  elements  are  defined  by  ASC  X12. 

•  Optional 

Optional  data  elements  are  used  at  the  discretion  of  the  sending 
party  or  are  based  upon  mutual  agreement  between  trading 
parmers. 

•  Required 

Required  data  elements  are  considered  optional  under 
ASC  X12  rules  but  are  required  by  DoD  decision. 

•  Recommended 

Recommended  data  elements  are  considered  optional  under 
ASC  X12  rules  and  by  the  DoD,  but  the  industry  recommends 
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824  Application  Advice 

This  Standard  provides  the  lormat  and  estaoiishes  the  data  contents  of  the 
Application  Advice  Transaction  Set  (824)  within  the  context  of  an  Electronic 
Data  Interchange  (EDO  environment  This  transaaion  set  provides  the  ability 
to  report  the  results  of  an  application  system  $  data  content  edits  ot 
transaction  sets  The  results  ot  editing  transaction  sets  can  be  reported  at  the 
lunctional  group  and  transaction  set  level,  m  either  coded  or  tree'torm  format 
It  IS  designed  to  accomodate  the  business  need  ot  reporting  the  acceptance, 
refection  or  acceptance  with  change  of  any  transaction  set.  The  Application 
Advice  should  not  be  used  in  place  ot  a  transaction  set  designed  as  a 
specific  response  to  arwther  transaction  set  (e  g.,  purchase  order 
acknowledgement  sent  in  response  to  a  purchase  order). 
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Figure  1.4-1  Example  of  a  Transaction  Set  Table 
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BGN  ■  BEGINNING  SEGMENT  ANSI  ASC  X13  VENSION^ELEASE  003010000. 


I  S«gm«nt:  BGN  8«ginning  Sogmsm 

I  LovBl;  Header 

*  !  Loop:  _ 

Manoatofv  Usage:  Mandatory 

Max  Use:  i 

Purpose:  To  indicate  tne  beginning  of  a  transaction  set 
Syntax:  if  BQNOS  is  used.  BGN04  is  required 
Comments:  l.  BGN02  is  trie  Transaction  Set  Reterence  Number 

2.  BGN03  IS  the  Transaction  Set  Date 

3.  BGN04  is  the  Transaction  Set  Time 

4.  BGN05  is  the  transactnn  set  time  quairtter 


Oatt  Elemem  Summer 

BQNOi  333  Transaetlofi  Set  Purpose  Code 

Code  Oentifying  purpote  of  trarwecmn  tet. 

00  Onginet 
01  Cencelletion 
04  Chengs 
12  Not  Processed 


BQNOa 

127 

Reterenes  Number  M  AN 

Reference  number  or  Oentificeiion  number  as  defined  for  a  particular 
Transactnn  Set.  or  as  specified  by  the  Reference  Number  QuaMier. 

1/30 

BON03 

373 

Data  M  DT 

Oats  (YYMMOO). 

6« 

BQNOA 

337 

Time  C  TM  4/4 

T«ne  emressed  in  244iour  dock  time  (HHMM,  time  range:  0000  though  2359). 

Imptatmnrnion  Note; 

UuHHMM. 

BONOS  623  Thne  Cede 


OA01  •JANUARY  20  10B3 


Figure  1 .4-2  Example  of  a  Transaction  Set  Segment 
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their  use  to  facilitate  EDI.  Most  companies  in  the  industry 
are  expected  to  use  this  data  element. 

Not  Used 

“Not  Used”  data  elements  are  those  that  DoD  docs  not  use. 
Conditional 

Conditional  data  elcrr-nts  depend  on  the  presence  of  other  data 
elements  in  the  transaction  set. 
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2.0  MAINTENANCE 


This  chapter  describes  the  procedures  for  maintaiaing  the  DoD 
conventions.  It  also  presents  a  section  on  version/rciease  timing. 

2.1  MAINTAINING  CONVENTIONS 

{Reserved} 

2.2  VERSION/RELEASE  TIMING 

Identification  of  the  official  “version”  of  a  standard  is  critical  to 
the  successful  interchange  of  information.  Each  participant  must 
be  able  to  send  and  receive  the  same  version  to  ensure  the  accuracy 
of  the  information  exchanged. 

The  version  is  transmitted  as  a  12-character  code  in  the  Functional 
Group  Header  segment  (GS)  in  Data  Element  #480,  Ver- 
sion/Release/Industry  ID.  This  12-character  code  is  used  by 
ASC  X12  as  follows: 


Po.sitinn 

CoQtcni 

1-3 

Version  number 

4-5 

Release  level  of  version 

6 

Subrelease 

7-12 

DoD/Industry  or  Trade  Association  ID 

ASC  X12  assigns  the  codes  in  PosiUons  1  through  6. 

The  version  number  (001,  002,  003,  etc.)  will  change  only  after  an 
official  public  review  cycle  leads  to  republication  of  a  new 
American  National  Standard. 

The  release  level  of  each  new  major  version  (Positions  4-6  in  the 
Functional  Group  Header)  will  begin  at  “000”  and  increased  by  1 
for  each  new  ASC  X12  approved  publication  cycle,  usually  once 
a  year.  The  fourth  and  fi^  characters  designate  the  release  and 
the  sixth  character  designates  the  subrelease. 

The  DoD  Industry  Trade  Association  ID  (Position  7-12)  is  used 
to  identify  conventions.  For  this  suffix,  DoD  will  use  “DoD_” 
with  the  lOtb  character  identifying  successive  publications.  The 
1  Ith  and  12tb  characters  may  be  used  by  the  Military  Departments 
or  Defense  agencies. 

DoD  conventions  for  using  ASC  X12  standards  are  published 
annually.  Conventions  developed  for  each  release  will  be  main¬ 
tained  for  4  years.  Military  Services  and  DoD  agencies  will 
determine  which  release  to  use  on  the  basis  of  business  need  but 
will  not  use  any  release  more  than  4  years  old  without  approval 
by  the  OUSD  (A  &  T)  CALS/EDI. 
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3.0  DoD  CONVENTIONS  FOR  USING 
ASC  X12  TRANSACTION  SETS 


This  chapter  defines  .he  DoD  transaction  set  conventions.  It 
includes  the  instructions  for  implementing  the  control  structure  and 
definitions  of  the  usage  indicators  and  applicable  codes 


3.1  INTRODUCTION 

The  power  of  the  ASC  X12  standard  is  in  its  building  block 
concept,  which  standardizes  the  essential  elements  of  business 
transactions.  The  concept  is  analogous  to  a  "standard  bill  of 
materiels  and  the  construction  specifications,"  which  gives  the 
architect  flexibility  in  what  can  be  designed  with  standardized 
materiels  and  procedures.  The  EDI  system  designer,  like  the  ar¬ 
chitect,  uses  the  ASC  XI 2  standards  to  build  business  transactions 
that  are  often  different  because  of  their  function  and  yet  uti’ize  the 
ASC  X12  standards.  The  “bill  of  materiels  and  the  construction 
specification”  of  ASC  X12  are  the  standards  found  in  the  published 
technical  documentation. 

ASC  X12.3  -  The  Data  Element  Dictionary  specifies  the  data 
elements  used  in  the  construction  of  the  segments  t'’2t  comprise 
the  transaction  sets  developed  by  ASC  XI 2. 

ASC  X12.5  -  The  Interchange  Control  Structure  provides  the 
interchange  control  segment  (also  called  an  envelope)  of  header 
and  trailer  for  the  electronic  interchange  thr~ugh  a  data  transmis¬ 
sion;  it  also  provides  a  structure  to  acknowledge  the  receipt  and 
processing  of  the  envelope 

ASC  X12.6  -  The  Application  Control  Structure  defines  the  basic 
control  structures,  syntax  rules,  and  semantics  of  EDI. 

ASC  XI  2.22  -  The  Data  Segment  Directory  provides  the  defini¬ 
tions  and  specifications  of  the  segments  used  in  the  construction 
of  transaction  sets  developed  by  ASC  XI 2. 

The  DoD  convention  in  Section  3.4  conforms  to  the  above  stand¬ 
ards,  and  each  transaction  set  is  a  complete  document  to  the  extent 
possible.  For  further  clarification  of  acronyms,  abbreviations,  and 
codes,  refer  to  ASC  XI 2  published  technical  documentation.  For 
copies,  contact  either  the  OUSD  (A  &  T)  CALS/EDI  or  the  Data 
Interchange  Standards  Association,  Inc.,  Suite  355,  1800  Diagonal 
Road,  Alexandria,  VA  22314 

3.2  CONTROL  SEGMENTS 

In  addition  to  the  communication  control  structure,  the  EDI  structure 
provides  the  standards  user  with  multiple  levels  of  control  to  ensure 
data  integrity.  It  does  so  by  using  header  and  trailer  control  segments 
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designed  to  identify  uniquely  the  start  and  end  of  the  interchange 
functional  groups  and  transaction  sets.  The  relationship  of  these 
control  segments  is  shown  in  Figure  3.2- 1.  Control  Segment 
specificaticms  are  defined  in  Section  3.2.2. 

3.2.1  Description  of  Use 

The  interchange  header  and  trailer  segments  surround  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions; 

•  Define  the  data  element  separators  and  data  segment  ter¬ 
minators 

•  Identify  the  sender  and  receiver 

•  Provide  control  information 

•  Allow  for  authorization  and  security  information. 

The  Interchange  Acknowledgment  Segment  is  used  to  acknowledge 
one  interchange  header  and  trailer  envelope  where  the  envelope 
surrounds  one  or  more  functional  groups.  (No  acknowledgment  is 
made  for  the  interchange  acknowledgment.) 

The  interchange  control  number  value  in  the  acknowledgment 
(TAl  segment)  is  the  same  as  that  for  the  ISA  segment  that  is 
being  acknowledged.  The  control  number  serves  as  a  link  between 
the  interchange  header  and  trailer  and  the  acknowledgment  of  that 
header  and  trailer. 

The  interchange  acknowledgment  does  not  report  any  status  on  the 
functional  groups  contained  in  the  interchange  and  is  separate 
from  the  communication  system’s  error  procedures. 

The  preparer  of  the  interchange  header  and  trailer  indicates  the 
level  of  acknowledgment  in  Data  Element  113,  Acknowledgment 
Requested.  If  an  acknowledgment  is  requested,  then  the  recipient 
must  return  an  acknowledgment.  If  not  requested,  none  should  be 
given. 

The  interchange  acknowledgment  control  segments  are  placed  after 
the  interchange  header  and  before  the  first  functional  group  or 
before  the  interchange  trailer  if  there  are  no  functional  groups. 

Control  segments  are  standard  for  all  implementation  conventions 
produced  for  the  Department  of  Defense.  Some  codes  associated 
with  individual  data  elements  within  the  control  segments  are 
unique  to  the  individual  transaction  set.  Others,  identify  the  ANSI 
version  and  release  in  which  the  convention  is  written. 
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Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mairdatory 


Segment:  ISA  interchange  Control  Header 

Purpose:  To  start  and  identify  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 

Data  Element  Summa 


DATA 

ELEMENT  NAME 


ISA01  I01  Authorization  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Authorization  Information. 

00  No  Authorization  Information  Present  (No  Meaningful  Information  in  102) 

ISA02  102  Authorization  Information  M  AN  10/10 

information  used  for  additional  identification  or  authorization  of  the  sender  or  the 
data  in  the  interchange.  The  type  of  information  is  set  by  the  Authorization 
Information  Qualifier. 

Implementation  Note: 

If  no  authorization  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA03  103  Security  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Security  Information. 

01  Password 

ISA04  104  Security  Information  M  AN  10/10 

This  is  used  for  identifying  the  security  information  about  the  sender  or  the  data 
in  the  interchange.  The  type  of  information  is  set  by  the  Security  Information 
Qualifier. 

Implementation  Note: 

An  agreed  upon  password.  If  no  security  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA05  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

An  agreed  upon  designation  of  DoD  Activity  Address  Code  ( DoDAAC)  or  other  code  coordinated 
with  the  value-adu  Jil  network  (VAN). 

ISA06  106  Interchange  Sender  ID  M  ID  15/15 

Identification  code  published  by  the  sender  for  other  parties  to  use  as  the 
receiver  ID  to  route  data  to  ti^em.  The  sender  always  codes  this  number  in  the 
sender  ID  element. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 

ISA07  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structcre  used  tu  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 


ISA06 
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Code  Value  Implementation  Note: 

An  agreed  upon  designation  of  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  (VAN). 

Mandatory  ISA08  107  Interchange  Receiver  ID  M  ID  15/15 

Identification  code  published  by  the  receiver  of  the  data.  When  sending,  it  is 
used  by  the  sender  as  their  sending  ID,  thus  other  parlies  sending  to  them  will 
use  this  as  a  receiving  ID  to  route  data  to  them. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  ( DoDAAC )  or  other  code  coordiruxted  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISA05  and 
coordiruned  with  the  VAN. 

Mandatory  ISAOf)  108  Interchange  Date  M  DT  6/6 

Date  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  YYMMDD 

Mandatory  ISA  10  109  Interchange  Time  M  TM  4/4 

Time  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  HHMM 

Mandatory  ISA11  110  interchange  Control  Standards  Identifier  M  ID  1/1 

Code  to  identify  the  agency  responsible  for  the  control  standard  used  by  the 
message  that  is  enclosed  by  the  interchange  header  and  trailer. 

U  U.S.  EDI  Community  of  ASC  XI 2.  TDCC,  and  UCS 

Mandatory  ISA12  111  Interchange  Control  Version  Number  M  ID  5/5 

This  version  number  covers  the  interchange  control  segments  and  the  functional 
group  control  segments. 

00303  Draft  Standard  for  Trial  Use  Approved  for  Publication  by  ASC  XI 2  Procedures 
Review  Board  Through  October  1 992 

Code  Value  Implementation  Note: 

Version  ID  as  defined  or  agreed  upon  by  the  trading  partners. 

Mandatory  ISA13  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender,  it  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

Mandatory  ISA14  113  Acknowledgment  Requested  M  ID  1/1 

Code  sent  by  the  sender  to  request  an  interchange  acknowledgment. 

0  No  Acknowledgment  Requested 
1  Interchange  Acknowledgment  Requested 

Mandatory  ISA15  114  Test  Indicator  M  ID  1/1 

Code  to  indicate  whether  data  enclosed  by  this  interchange  envelope  is  test  or 
production. 

P  Production  Data 
T  Test  Data 
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Mandatory 


Code  Value  Implementation  Note: 

Assigned  by  translaiion  software. 

ISA16  115  Subelement  Separator  M  AN  1/1 

This  is  a  field  reserved  for  future  expansion  in  separating  data  element 
subgroups.  (In  the  interest  of  a  migration  to  international  standards,  this  should 
be  different  from  the  data  element  separator). 

Implementation  Note: 

Use  character 
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Segment:  GS  Functional  Group  Header 

Purpose:  To  indicate  the  beginning  of  a  functional  group  and  to  provide  control 
information 


Syntax:  The  data  interchange  control  number  (GS06)  in  this  header  must  be 
identical  to  the  same  data  element  in  the  associated  Functional  Group 
Trailer  (GE02). 

Comment:  A  functional  group  of  related  transaction  sets,  within  the  scope  of  X1 2 

standards,  consists  of  a  collection  of  similar  transaction  sets  enclosed  by 
a  functional  group  header  and  a  functional  group  trailer. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

RIF.  DATA 

DP.  ILmmt  MAM _ ATTRIRUTP 

GS01  479  Functional  Identifier  Code  M  ID  2/2 

Code  identifying  a  group  of  application  related  Transaction  Sets. 

Implementation  Note: 

Choose  the  code  value  appropriate  to  the  information  content  of  the  functional  group.  See  X12  Dictionary  for 
source  code  list. 

SP  Specifications/Technical  Information  (841) 

GS02  142  Application  Sender’s  Coda  M  AN  2/15 

Code  identifying  party  sending  transmissbn.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  For  increased  security,  non-DoD  code  should  differ  from  that 
used  in  ISA06. 


Mandatory 


GS03  124  Application  Receiver’s  Code  M  AN  2/15 

Code  identifying  party  receiving  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  For  increased  security,  non-DoD  code  should  differ  from  that 
used  in  ISA08. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


GS04 

373 

Date 

Date  sender  generated  a  transaction  set. 

M 

DT 

6/6 

GS05 

337 

Time 

Time  expressed  in  24'hour  clock  time. 

M 

TM 

4/6 

GS06 

28 

Group  Control  Number 

Assigned  number  originated  and  maintained  by  the  sender. 

M 

NO 

1/9 

Implementation  Note: 

Assigned  by  translation  software. 

GS07 

455 

Responsible  Agency  Code 

M 

ID 

1/2 

Code  used  in  conjunction  with  Data  Element  480  to  identify  the  issuer  of  the 
standard. 


X  Accredited  Standards  Committee  XI 2 
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Mandatory 


Code  Value  Implementation  Note: 

Indicates  that  an  Af^SI  XI2  standard  is  being  transmitted. 

GS08  480  VersionyRelease/Industry  ID  Code  M  ID  1/12 

Code  indicating  the  version,  release,  subrelease  and  industry  identifier  of  the  EDI 
standard  being  used.  Positions  1-3,  version  number;  positions  4-6,  release  and 
subrelease  level  of  version;  positions  7-12,  industry  or  trade  association  identifier 
(optionally  assigned  by  user). 

003030  Draft  Standards  Approved  by  ASC  XI 2  Through  October  1992. 

Code  Value  Implementation  Note: 

Code  value  agreed  to  by  trading  partners.  SeeX12  Dictionary  for  source  code  list. 
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Segment:  GE  Functional  Group  Trailer 

Purpose:  To  indicate  the  end  of  a  functional  group  and  to  provide  control 
information 


Syntax:  The  data  interchange  control  number  (GE02)  in  this  trailer  must  be 

identical  to  the  same  data  element  in  the  associated  Functional  Group 
Header  (GS06). 

Comment:  The  use  of  identical  data  interchange  control  nurriiers  in  the  associated 
functional  group  header  and  trailer  is  designed  to  maximize  functional 
group  integrity.  The  control  number  is  the  same  as  that  used  in  the 
corresponding  header. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

RIF.  DATA 

OIS. _ ILIMIKT  MAMI  ATTHmUTIS 

GE01  97  Number  of  Transaction  Sets  Included  M  NO  1/6 

Total  number  of  transaction  sets  included  in  the  functional  group  or  interchange 
(transmission)  group  terminated  by  the  trailer  containing  this  data  element. 

Implementation  Note: 

Assigned  by  translation  software. 

Gp02  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  control  number  of  the  preceding 
GS06  control  number. 
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Mandatory 


Segment:  lEA  Interchange  Control  Trailer 

Purpose:  To  define  the  end  of  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 

_ Data  Element  Summary _ 

REF.  DAT* 

DES  ELEMEWT  HAKE _ ATIRIRUTES 

IEA01  116  Number  of  Included  Functional  Groups  M  NO  1/5 

A  count  of  the  number  of  functional  groups  Included  in  a  transmission. 

Implementation  Note: 

Assigned  by  translation  software. 

IEA02  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  ctmjrol  number  must  match  the  number  that  occurs  in  ISA13 . 
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DEFiymoN 


SE*841*000l 


This  is  an  841  transaction  set  with  a  control  number  of  0001. 


SPI*92*TN*841RES001«***11*DW*02  n/l 


The  data  provided  in  this  transaction  set  arc  classified 
government  confidential  (Code  92).  The  transaction  set 
reference  number  (Code  TN)  is  841R£S001.  This  is  a 
response  (Code  11)  to  a  rc<iuest  and  is  providing  drawings 
(Code  DW).  The  data  provided  have  a  commercial  protection 
requirement  of  company  confidential  (Code  02). 


REF*TN*841RES001  n/l 


The  unique  reference  number  (Code  TN)  of  this  transaction 
setis841RES001. 


DTM*097*930710n/I 


The  date  of  this  transaction  set  (Code  097)  is  July  10, 1993 


R£F*ZZ*841REQ001  n/l 


The  unique  reference  number  (Code  ZZ)  of  the  transaction  set 
to  which  this  response  pertains  is  841REQ001. 


DTM*368»930707  n/l 


The  date  of  the  referenced  transaction  set  (Code  368)  is  July  7, 
1993 


N1*BY*«10*N00019  n/I 


The  data  is  being  provided  by  a  buying  activity  (Code  BY) 
whose  DoDAAC  (Code  10)  is  N00019 


Nl*TO**33*B1234  n/I 


The  data  are  being  provided  to  (Code  TO)  a  company  whose 
CAGE  code  (Code  33)  is  B1234. 


PER*IC*Nicoie  Kidman*EM*EMT13NH8 
n/I 


The  point  of  contract  at  the  originator's  organization  (Code 
IC)  is  Nicole  Kidman.  Her  electronic  mail  address  is 
EMT13NH8. 


HL*1**A*1  n/l 


This  is  the  first  iteration  of  the  HL  segment  as  specified  by  the 
number  1.  It  has  no  parent  The  hierarchical  l^el  is  the 
assembly  (Code  A)  There  is  a  child  (Code  1). 


SPI*92*DG*12E2211******02  n/l 


The  drawing  number  (Code  DG)  being  provided  is  12E2211. 
It  is  classified  government  confidential  (Code  92)  and  has  a 
commercial  protection  requiremoit  of  company  confidential 
(Code  02). 


RDT*E*A*007*880622  n/I 


Revision  (Code  E)  "A",  wifii  an  effective  date  of  June  22, 1988 
is  being  provided. 


rDT«e«B*007*910115  n/l 


Revision  (Code  E)  "B",  with  an  effective  date  of  January  15, 
1991  is  also  being  provided. 
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RDT*E*C*007*92Q314  n/l  Revision  (Code  E)  "C,  with  an  effective  date  of  March  14, 

1992  is  also  being  provided. 

EFI*92**9N*3.3*TrunkCAD*3.2*MIL<R>  The  data  provided  in  the  BIN  segment  are  classified 

28002*3.3*TRIM*AH*DRAW  n/l  government  confidential  (Code  92).  The  security  technique 

(Code  9N)  B  encryption.  It  was  created  using  an  application 
program  known  as  TrunkCad,  Version  3  J.  The  transfer 
format  used  is  Raster  (MIL>R-28002),  Version  3.2.  The  file 
was  compressed  using  the  TRIM  program.  Version  3  J.  The 
drawing  size  to  be  plotted  is  8.5  inches  x  11.0  inches  (Code 
AH).  The  name  of  the  file  containing  this  data  b  DRAW. 

B1N*11090S* _ n/l  The  binary  data  transmitted  arc  110908  octeb  in  length. 

HL*2*1*II*1  n/l  Thb  b  the  second  iteration  of  the  HL  segment  as  specified  by 

the  number  2.  Ib  parent  b  HL  1.  The  hierarchical  level  b  the 
subassembly  (Code  U).  It  has  a  child  (Code  1). 

SPI*92*DG*H12D406-30****'**02  n/l  The  drawing  number  ((Zode  DG)  being  provided  b  H12D40B« 

30.  It  b  classified  government  confidential  (Code  92)  and  hal 
a  commercial  protection  requirement  of  company  confidential 
(Code  02). 

EFI*92**9N*3  J*TrunkCAD*3JI*MIL-R-  The  data  provided  in  the  BIN  segment  arc  classified 

28002*3.3*TRIM*AH*DRAW  n/I  government  oonfideBtial  (Code  92).  The  security  technique 

(Code  9N)  b  encryption.  It  was  created  using  an  applicatioa 
program  known  as  TrunkCad,  Version  3  J.  The  transfer 
format  used  b  Raster  (MlL>R-28002),  Version  3.2.  The  file 
was  compressed  using  the  TRIM  program.  Version  3  J.  The 
drawing  size  to  be  plotted  b  SJ  inches  x  11.0  inches  (Code 
AH).  The  name  of  the  file  containing  thb  data  b  DRAW. 

BIN*130230* _ n/l  The  binary  data  transmitted  are  135230  octeb  in  length. 

HL*3*2*I*0  n/l  Thb  b  the  third  iteration  of  the  HL  segment  as  specified  by 

the  number  3.  Ib  parent  b  HL  2.  The  hierarchical  bvel  b  the 
item  (Code  D*  It  hu  no  child  (Code  0). 

SPI*90*S3*Z-R701  n/l  The  specification  number  (Code  S3)  being  provided  in  the  BIN 

segment  b  Z>R701.  It  b  government  non-dassified  (Code  90). 

RDT*E*K*007*930210  n/l  Revbion  (Code  E)  "K"  with  an  effective  date  of  February  10, 

1993  b  being  provided. 

The  data  provided  in  the  BIN  segment  b  government  non* 
classified  (Code  90).  It  was  created  using  an  application 
program  known  as  CAT,  Version  3.0.  The  transfer  format 
used  b  MCAD,  Version  3.2.  The  file  was  compressed  using 
the  FISH  program.  Version  2.8.  The  name  of  the  fib 
containing  thb  data  b  MILSPEC^ 

BIN*95678* _ n/I  The  binary  data  transmitted  are  95678  octeb  in  bngth. 


En*90***3.0*CAT*3.2*MCAD*2.8*FlSH 
••MILSPEC  nfi 
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HL*4*1*U*1  n/I  This  b  the  fourth  Iteration  of  the  HL  segment,  as  specified  by 

the  number  4.  Its  parent  b  HL  1.  The  hierarchical  level  b  the 
subassembly  (Code  U).  It  has  a  child  (Code  1). 

SPI*90«I>G*12E2213*****«06  n/I  The  drawing  number  (Code  DG)  being  provided  in  the  BIN 

segment  b  I2E2213.  It  b  government  non*classified  (Code  90) 
and  has  a  commercial  protection  reipiirement  of  company 
proprietary  (Code  06). 

EFI*90***3J*TrankCAD*3J*MIL*R-  The  data  provided  in  the  siN  segment  b  government  non* 

28002*3.3*TRIM*AH*DRAW  n/I  classified  (Code  90).  It  was  created  using  an  application 

program  known  as  TrunkCad,  Version  3  J.  Thetrandcr 
format  used  b  Raster  (MIL-R-28002),  Version  3.2.  The  file 
was  compressed  using  the  TRIM  program.  Version  3.3.  The 
drawing  nze  to  be  plotted  b  8.5  inches  x  Il.O  inches  (Code 
AH).  The  name  of  the  file  containing  thb  data  b  DRAW. 

BIN*130230* _ n/I  The  binary  data  transmitted  are  130230  octeb  in  length. 

HL*S*4*I*0  n/I  Thb  b  the  fifth  iteration  of  the  HL  segment  as  specified  by  the 

number  5.  Ib  parent  b  HL  4.  The  hierarchical  level  b  the 
item  (Code  I).  It  has  no  child  (Code  0). 

SPI*90*ZZ*fiM19285*BiU  of  Material  nfi  The  item  number  being  provided  (Code  ZZ),  BM19285,  b  a 

Bill  of  Material  and  b  government  non-classified  (Code  90). 

PID«F«**«BiU  of  Material  BM1928S  nfi  BiU  of  Material,  Number  BM19285,  wiU  be  sent  by  means 

other  than  in  the  BIN  segment  of  this  transaction  set 

PWK*SP*BM  n/I  The  Bin  of  Material  wiU  be  sent  by  maU  (Code  BM). 

ST*34*0001  n/I  Thb  transaction  set  whose,  control  number  b  0001,  contains 

34  segments. 
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841  Specifications/Technical  Information 

This  Draft  Standard  for  Trial  Use  contains  the  format  and  establishes  the  data  contents  of  the 
Specifications/Technical  Information  Transaction  Set  (841)  for  use  within  the  context  of  an 
Electronic  Data  Interchange  (EDI)  environment.  The  transaction  set  can  be  used  to  transmit 
specifications  or  technical  information  between  trading  partners.  It  can  be  used  to  allow  EDI 
trading  partners  the  ability  to  exchange  a  complete  or  partial  technical  description  of  a  product, 
process,  service,  etc.  over  the  same  path  as  any  other  EDI  transaction.  The  detail  area  can 
include  graphic,  text,  parametric,  tabular,  image,  spectral,  or  audio  data.  A  transmission  includes 
identification  information  to  assist  the  receiver  in  interpreting  and  utilizing  the  information 
included  in  the  transaction. 

Further  action  as  a  consequence  of  the  receipt  and  initial  processing  of  the  specification  or  other 
technical  data  may  or  may  not  require  human  intervention.  The  transmission  and  receipt  of  the 
data  may  require  private  agreement  between  the  trading  partners  to  automate  the  receipt  of  the 
data. 

The  total  transaction  must  be  in  the  general  form  of  all  ASC  X1 2  transactions  so  that  an  EDI 
computer  system  will  be  able  to  automatically  recognize  it  as  a  Specification/Technical 
Information  Transaction  Set  and  pass  it  on  for  processing  of  the  data  itself.  The  transaction  set 
is  not  media  dependent. 

The  detail  area  of  the  Specification/Technical  Information  Transacbon  Set  provides  a  structure 
which  allows  for  the  exchange  of  a  variety  of  specification  information.  For  example,  if  the 
transaction  contains  information  describing  a  complete  assembly,  it  would  be  necessary  to 
include  the  assembly  model,  the  models  for  each  of  the  individual  parts,  and  the  associated 
specifications.  In  the  case  of  a  process  it  may  be  necessary  to  transmit  the  specification  of  the 
product  along  with  the  specifications  of  the  process  and  raw  materials.  This  transaction  set  can 
also  be  linked  to  other  transacbon  sets. 

This  transacbon  set  is  not  limited  to  a  specific  transmission  protocol  and  uses  other  standards  as 
applicable  where  they  do  rrot  conflict  with  these  requirements  tor  specificabon  transacbon. 
Implementation  Notes 

1.  This  draft  implementation  convention  responds  to  a  request  or  to  a  follow-up  for  specifications/lechnical 
information.  It  can  also  be  used  to  provide  limited  status  to  the  originator  of  a  follow-up. 

2.  The  specifications/technical  information  provided  in  this  transaction  set  will  be  transmitted  in  the  BIN 
segment  unless  otherwise  specified  in  the  PWK  segment. 


PAGE*  POS.* 


5 

010 

6 

020 

N/U 

030 

8 

040 

N/U 

050 

N/U 

060 

N/U 

070 

N/U 

080 

9 

090 

Table  1 

SEG.ID  HAWE _ 

ST  Transaction  Set  Header 

ISoPIdTsw 

SPI  Specificabon  Idenbfier 

RDT  Revision  Date/Time 

NTE  Note/Special  Insbuction 

X1  Export  License 

X2  Import  License 

X7  Customs  Information 

GOV  Military  Standard  1 840-A  Record  Definition 
LOOPID-SfH/REF  ~ 

REF  Reference  Numbers 


REaDES.  MAX  USE 


LOOP  REPEAT 


M 


M 

O 

O 

O 

O 

O 

O 


1 

>1 

>1 

1 

1 

1 

>1 


>1 


1 
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10  100 

DTM 

N/U  110 

PER 

11  120 

N1 

12  130 

N2 

13  140 

N3 

14  150 

N4 

N/U  160 

REF 

IS  170 

PER 
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16 

010 

18 

020 

20 

030 

22 

040 

26 

045 

27 

27 

060 

N/U 

065 

N/U 

070 

N/U 

074 

N/U 

075 

N/U 

076 

29 

077 

N/U 

078 

N/U 

079 

N/U 

080 

N/U 

090 

N/U 

100 

N/U 

109 

N/U 

110 

N/U 

120 

N/U 

130 

30 

140 

N/U 

150 

32 

160 

N/U 

170 

N/U 

180 

N/U 

190 

N/U 

200 

N/U 

201 

Date/Time  Reference 
Administrative  Communications  Contact 


U>OP]D>Si«N1 

Name 

Additional  Name  Information 

Adc^ss  Information 

Geographic  Location 

Reference  Numbers 

Administrative  Communications  Contact 


Table  2 


SEaiD  NAME 


HL 

SPI 

ROT 

UN 

N1 

MSG 

PID 

PKD 

QTY 

MEA 

urr 

LOG 

PWK 

PKG 

MEA 

REF 

OTM 

PER 

LX 

MEA 

DTM 

REF 

EFI 

GOV 

BIN 

CID 

UIT 

TMD 

PSD 

CSS 


LOdPID'HL 

Hierarchical  Level 


O 

o 


>1 

>1 


o 

o 

o 

o 

o 

o 


1 

2 

2 

1 

>1 

>1 


REa  DES.  MAX  USE 


M 
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LOOP  REPEAT 


*►1 


LOOPI0.HUSPI 

SpecificaDon  Identifier 

O 

1 

Revision  Date/Time 

O 

>1 

Item  Identification 

0 

1 

Name 

o 

>1 

Message  Text 

o 

>1 

LOOPlD'HUPiD 

IpI 

Product/Item  Descnption 

o 

1 

Packaging  Description 

o 

>1 

Quantity 

o 

>1 

Measurements 

0 

>1 

Unit  Detail 

0 

>1 

Location 

0 

1 

Paperwork 

o 

>1 

Marking,  Packaging,  Loading 

o 

1 

Measurements 

o 

>1 

LOQPm-HUBEF 

>1 

Reference  Numbers 

0 

1 

Date/T me  Reference 

o 

>1 

Administrative  Communications  Contact 

0 

>1 

LOOPJD-HIAX 

>1 

Assigned  Number 

0 

1 

Measurements 

0 

1 

Date/Time  Reference 

o 

>1 

Reference  Numbers 

o 

>1 

LOOPiO>HL/Bn 

Electronic  Format  Identification 

o 

1 

Military  Standard  1840-A  Record  Definition 

o 

>1 

Binary  Data 

o 

>1 

LOOPID-^HUCID 

Characteristic/Class  ID 

o 

1 

Unit  Detail 

o 

1 

Test  Method 

0 

>1 

Physical  Sample  Description 

o 

1 

Conditional  Sampling  Sequence 

o 

1 
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N/U  210 
N/U  220 

N/U  230 
N/U  240 
N/U  250 

N/U  260 
N/U  270 
N/U  280 

N/U  282 
N/U  283 

N/U  2M 
N/U  285 
N/U  286 
N/U  287 

N/U  290 
N/U  300 
N/U  310 
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SPS 

MSG 

Sampling  Parameters  for  Summary  Statistics 
Message  Text 

O 

o 

1 

>1 

L<>OI*]P>M.ia»«EA 

>1 

MEA 

Measurements 

o 

1 

DTM 

Date/Time  Reference 

o 

>1 

REF 

Reference  Numbers 

o 

>1 

tOOI>}0«tft,/aD/STA 

>t 

STA 

Statistics 

o 

1 

DTM 

Date/Time  Reference 

o 

>1 

REF 

Reference  Numbers 

o 

>1 

CSF 

Conditional  Sampling  Frequency 

o 

1 

LS 

Loop  Header 

o 

1 

CID 

Characteristic/Class  ID 

o 

1 

MEA 

Measurements 

o 

1 

STA 

Statistics 

o 

1 

LE 

Loop  Trailer 

o 

1 

EFI 

Electronic  Format  Identification 

o 

1 

GOV 

Military  Standard  1840-A  Record  Definition 

o 

>1 

BIN 

Binary  Data 

o 

>1 

Table  3 

SEG.ID 

NAME 

REa  DES. 

MAX  USE 

LOOPREmT 

SE 

Transaction  Set  Trailer 

M 

1 

NOTES: 

2/010  To  be  meaningful,  at  least  one  of  the  SPI,  PID,  REF,  MEA,  EFI  or  CID  loops 
must  be  present  with  each  occurence  of  the  HL  loop. 

2/020  The  HL  segment  may  be  used  to  define  the  hierarchical  relationship  of  product-re¬ 
lated  specifications  reported  in  the  associated  HL  loop.  Product-related  specifica¬ 
tions  may  refer  to  the  product  in  its  entirety  or  to  subunits  of  the  product.  For 
example,  if  the  top  level  refers  to  an  assembly,  the  second-level  HL  segment 
may  refer  to  parts  or  subassemblies  of  the  top  assembly.  This  pattern  may  be 
repeated  as  often  as  required. 

2/170  The  CID  segment  may  be  used  to  define  either  a  general  class  of  properties, 
such  as  physical  properties,  or  an  individual  property  within  a  class.  The  CID 
loop  allows  the  user  the  exility  to  define  specifications  such  as  the  properties  of 
the  item  or  class,  the  environmental  conditions  under  which  the  specifications 
apply,  the  test  methods  to  be  used,  and  other  parameters  related  to  properties 
within  the  current  HL  hierarchical  level. 

2/201  The  sampling  sequence  specified  in  the  CSS  segment  will  take  precedence  over 
any  other  sampling  rate  (PSD03,  PSD09,  SPS06,  CSF02,  and  CSF03)  from  the 
point  the  CSS01  event  occurs  until  the  specified  sequence  is  completed. 

2/201  If  no  other  sampling  is  specified,  then  only  the  sampling  indicated  in  this  segment 
is  performed  when  the  CSS01  event  occurs. 
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2/282  The  sampling  rate  specified  is  the  CSF  segment.  It  would  take  precedence  over 
the  normal  sampling  rate  specified  in  PSD03  while  the  conditions  of  the  CSF  seg¬ 
ment  are  satisfied,  but  would  NOT  take  precedence  over  the  sampling  sequence 
activated  by  the  proposed  CSS  segment. 

2/282  If  no  other  sampling  rate  is  specified,  then  the  only  sampling  indicated  in  the  CSF 
segment  is  performed  while  the  CSF  conditions  are  met.  Sampling  will  cease 
when  the  conditions  are  no  longer  met. 

2/282  Conditional  values  specified  in  DE  740  (Range  Minimum)  will  be  interpreted  as 
“greater  than  or  equal  to  this  value.”  Values  specified  in  DE  741  (Range  Maxi¬ 
mum)  will  be  interpreted  to  mean  “less  than  or  equal  to  this  value." 

2/282  Repetitions  of  the  CSF  loop  allow  several  frequency  changes  (and  e  conditions 
that  would  trigger  those  changes)  to  be  specified. 

2/282  If  the  conditions  are  such  that  several  CSF  values  are  activated  at  the  same 
time,  the  value  with  the  highest  sampling  rate  shall  prevail. 

2/284  Either  the  MEA  segment  or  the  ST  A  segment  must  occur,  but  not  both. 

2/284  The  CIO  loop  within  the  CSF  loop  is  used  to  specify  the  conditions  that  will  trig¬ 
ger  activation  of  the  conditional  value  in  the  CSF  segment. 

2/284  Repetitions  of  the  CID  loop  will  have  an  implied  logical  AND  between  the  condi¬ 
tions  set  in  each  iteration. 

2/285  The  elements  of  the  CID  segment  identify  the  conditional  property.  If  the  property 
is  a  measurement  from  within  the  manufacturing  process  of  a  plant  environment, 
rather  than  the  product,  the  segment  also  identifies  the  location  where  the  meas¬ 
urements  are  to  be  observed. 

2/286  If  the  condition  is  based  on  single  test  measurements,  the  MEA  segment  is  used 
to  specify  the  units  of  measure,  and  the  open  or  closed  numeric  range  of  the  con¬ 
ditional  test. 
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Mandatory 


Segment:  ST  Transaction  Set  Header 
Level:  Header 


Loop:  _ 

Usage:  Mandatory 
Max  Use:  1 

Purpose;  To  indicate  the  start  of  a  transaction  set  and  to  assign  a  control  number 

Semantic:  The  transaction  set  identifier  (ST01 )  used  by  the  translation  routines  of 
the  interchange  partners  to  select  the  appropriate  transaction  set 
definition  (e.g.,  810  selects  the  invoice  transaction  set). 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

RIP.  DATA 

OIS.  ILBICKT  _ ATTWRUTIS 

ST01  143  Transaction  Set  Identifier  Code  M  ID  3/3 

Code  uniquely  identifying  a  Transaction  Set. 

841  XI 2.51  Specifications/Technical  Information 

ST02  329  Transaction  Set  Control  Number  M  AN  4/9 

Identifying  control  number  that  must  be  unique  within  the  transaction  set 
functional  group  assigned  by  the  originator  for  a  transaction  set 

Implementation  Note: 

This  unique  control  number  is  assigned  by  the  originator  of  the  transaction  set  or  by  the  originator's 
application  program.  This  same  number  is  carried  in  SE02. 
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Mandatory 


Segment:  SPI  Specification  identifier 
Level:  Header 
Loop:  SPI  Repeat:  >1 
Usage:  Mandatory 
Max  Use:  1 

Purpos;i:  To  provide  a  description  of  the  included  specification  or  technical  data 
items. 


Mandatory 


_ Data  Element  Summary _ 

REF.  OAT* 

DCS.  ELiUEKT  KAMt _ ATTRaUTES 

SPI01  786  Security  Level  Code  M  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  any  code. 

2.  If  the  data  being  transmitted  have  both  a  government  security  classification  and  a  commercial  security 
protection  requirement,  then  this  data  elemera  will  carry  the  government  security  classification  code  and  the 
commercial  security  protection  code  will  be  carried  in  SPI09. 

3.  If  the  data  being  transmitted  have  only  one  protection  requiremeru,  then  this  data  element  can  carry  either 
the  government  security  classification  code  or  the  commercial  security  protection  code. 

4.  Use  this  data  element  to  indicate  the  highest  pc'^teciion  level  (government  or  commercial)  assigned  to  the 
data  being  provided.  Use  the  SPI  segment  at  the  Detail  level  to  indicate  the  protection  level  of  individual  data 
items. 


Mandatory 


Mandatory 


Not  Used 
Not  Used 
Not  Used 
Required 


SPI02  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

TN  Transaction  Reference  Number 
Code  Value  Implementation  Note: 

Use  Code  TN  for  the  unique  reference  number  of  this  transaction  set. 

SPI03  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Implementation  Note: 

This  is  the  unique  number  of  this  transaction  set. 


SPI04 

790 

Entity  TKIe 

0 

AN 

1/132 

SPI05 

791 

Entity  Purpose 

O 

AN 

1/90 

SPI06 

792 

Entity  Status  Code 

o 

ID 

1/1 

SPI07 

353 

Transaction  Set  Purpose  Code 

Code  identifying  purpose  of  transaction  set. 

0 

ID 

2/2 

Implementation  Note: 

Use  any  appropriate  listed  code. 

08  Status 
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Optional 


Code  Value  Implementation  Note: 

Use  Code  08  to  indicate  the  request  to  which  this  transaction  sd  is  responding  cannot  be  satisfied 
Provide  an  explanation  in  the  NTE  segment.  When  Code  08  is  used,  only  the  HL  segment  (HLOl 
and  HL03 )  at  the  Detail  level  iTable  2 )  is  needed 

11  Response 

Code  Value  Implementation  Note: 

Use  Code  1 1  for  a  response  to  a  request  or  follow-up  for  specificationsite''hwiral  information. 

SPI08  755  Report  Type  Code  O  ID  2/2 

Code  indicating  the  title  or  contents  of  a  document,  report  or  supporting  item 

Implementation  Note: 

Any  code  may  be  used  hut  typically  Code  DW  or  Code  SP  are  used. 


Optional 


NotUaad 
Not  Used 
Not  Used 


SPI09  786  Security  Level  Code  O  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  this  data  element  ONLY  when  SPlOl  is  Code  90,  92,  93,  94,  or  99,  and  the  data  being  provided  also 
have  a  commercial  security  protection  requirement. 

2.  Use  this  data  element  to  indicate  the  highest  level  of  commercial  security  p-otection  assigned  to  the  data 
being  provided.  Use  the  SPI  segment  at  the  Detail  level  to  indicate  the  commercial  security  protection  of 
individual  data  items. 

00  Company  Non-Classified 
01  Company  Internal  Use  Only 
02  Company  Confidential 

03  Company  Confidential,  Restricted  (Need  to  Know) 

04  Company  Registered  (Signature  Required) 

05  Personal 

09  Company  Defined  (Trading  Partner  Level) 


SPI10 

559 

Agency  Qualifier  Code 

0 

ID 

2/2 

SPI11 

916 

Code  List  Reference 

O 

AN 

1/6 

SPI12 

554 

Assigned  Number 

O 

NO 

1/6 
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Optional 


Segment:  NTE  Note/Special  Instaiction 
Level:  Header 


Loop:  SPI 
Usage:  Optional 
Max  Use:  >1 


Purpose:  To  transmit  information  in  a  tree-form  format,  if  necessary,  for  comment 
or  special  instruction 

Comment:  The  NTE  segment  permits  free-form  information/data  which  under  ANSI 
X12  standard  implementations,  is  not  machine  processable.  The  use  of 
the  “NTE"  segment  should  therefore  be  avoided,  if  at  ail  possible,  in  an 
automated  environment. 


Implementation  Note: 

Use  this  segment  to  provide  information  pertinent  to  the  entire  transaction  set.  To  provide 
information  relative  to  a  specific  data  item,  use  the  MSG  segment  in  Table  2. 


Optional 


Mandatory 


_ Data  Element  Summary _ 

RCF  DATA 

DtS _ ELiMEWr  MAMt _ ATmuuTES 

NTE01  363  Note  Reference  Code  O  ID  3/3 

Code  identifying  the  functional  area  or  purpose  for  which  the  note  applies. 

GEN  Entire  Transaction  Set 

Code  Value  Implementation  Note: 

Use  Code  GEN  for  any  notes  that  relate  to  the  entire  transaction  set. 

NTE02  3  Free  Form  Message  M  AN  1/60 

Free-form  text. 
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Optional 


Segment:  REF  Reference  Numbers 
Level:  Header 

Loop:  SPI/REF  Repeat;  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  specify  identifying  numbers. 

Syntax:  R0203  —  At  least  one  of  REF02  or  REF03  is  required. 
Implementation  Note: 

This  REF  segment  should  be  used  to  provide  appropriate  reference  numbers  relative  to  the  data 
being  provided. 


Data  Element  Summa 


OAT* 

ELOUKT  NAME 


Mandatory 


Conditional 


Not  Used 


REF01  128  Reference  Number  Qualifier  M  ID 

Code  qualifying  the  Reference  Number. 

C4  Change  Number 
Code  Value  Implementation  Note: 

Use  Code  C4  for  the  contract  modification  number  to  which  the  data  being  provided  pertain. 

CT  Contract  Number 
Code  Value  Implementation  Note: 

Use  Code  CT  for  the  contract  number  to  which  the  data  being  provided  pertain. 

KS  Solicitation 

Code  Value  Implementation  Note: 

Use  Code  KS  for  the  solicitation  number  to  which  the  data  being  provided  pertain. 

TN  Transaction  Reference  Number 
Code  Value  Implementation  Note: 

Use  Code  TN  for  the  unique  reference  number  of  this  transaction  set. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  ZZfor  the  unique  reference  rutmber  of  the  transaction  set  to  which  the  data  in  this 
transaction  set  pertain. 

REF02  127  Reference  Number  C  AN 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

REF03  352  Description  C  AN 
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DRAFT  HMPLEMENTATION  CONVENTION 


ANSI  ASC  XI 2  VERSION/RELEASE  003030DOD_ 


841  • RESPONSE 
DTM  •  DATEn^lME  REFERENCE 


Optional 


Segment:  DTM  Date/Time  Reference 
Level:  Header 
Loop:  SPI/REF 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  specify  pertinent  dates  and  times 
Syntax:  R0203  —  At  least  one  of  DTM02  or  DTM03  is  required. 


Mandatory 


_ Data  Element  Summary _ 

RCF.  DATA 

PCS.  MLgMgifr  WAME _ _ _ _ _ ATfWOTES 

DTM01  374  Date/Time  Qualifier  M  ID  3/3 

Code  specifying  type  of  date  or  time,  or  both  date  and  time. 

092  Contract  Effective 
Code  Value  Implementation  Note: 

When  REFOl  is  Code  CT,  use  Code  092  to  indicate  the  date  of  the  contract  specified  in  REF02. 

097  Transaction  Creation 

Code  Value  Implementation  Note: 

When  REFOl  is  Code  TN,  use  Code  097  to  irulicate  the  creation  date  of  this  transaction  set. 

152  Effective  Date  of  Change 
Code  Value  Implementation  Note: 

When  REFOl  is  Code  C4,  use  Code  152  to  indicate  the  date  of  the  contract  modification  specified 
inREF02. 

368  Submittal 

Codie  Value  Implementation  Note: 

When  REFOl  is  Code  72^  use  Code  368  to  indicate  the  date  of  the  referenced  transaction  set 
specified  in  REF02. 

993  Request  for  Quotation 
Code  Value  Implementation  Note: 

When  REFOl  is  Code  KS,  use  Code  993  to  indicate  the  date  of  the  solicitation  specified  in  REF02. 


Conditional 

Not  Used 
Not  Used 
Not  Used 


DTM02 

373 

Date 

Dale  (YYMMDD). 

DTM03 

337 

Time 

DTM04 

623 

Time  Code 

DTM05 

624 

Century 

C 

DT 

6/6 

C 

TM 

4/6 

0 

ID 

2/2 

0 

NO 

2/2 
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DEPARTMENT  OF  ODENSE 
DRAFT  IMPLEMENTATKM  CONVENTION 


841  •  RESPONSE 
N1  •  NAME 


ANSI  ASC  X12  VERSION/RELEASE  003030DO0 


Optional 


Segment:  N1  Name 
Level:  Header 
Loop:  SPI/N1  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 


Purpose:  To  identify  a  party  by  type  of  organization,  name  and  code 

Symax:  1.  R0203  —  At  least  one  of  N1 02  or  N1 03  is  required. 

2.  P0304  —  If  either  N1 03  or  N104  is  present,  then  the  other  is  required. 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  "ID 
Code”  (N104)  must  provide  a  key  to  the  table  maintained  by  the 
transaction  processing  party. 


Implementation  Note: 

Whenever  possible,  identification  and  address  information  should  be  provided  using  NlOl,  N103, 
and  NI04.  Use  N102  and  segments  N2  through  N4  when  that  information  cannot  be  provided  by 
use  of  a  CAGE  code  or  a  DoDAAC. 


Mandatory 


Conditional 


_ Data  Element  Summary _ 

BtS.  ELmtWT  MMHE  _ ATTWIITtS 

N101  98  Entity  ldentifi«r  Code  M  ID  2/2 

Code  identifying  an  organizational  entity,  a  physical  location,  or  an  individual 

BY  Buying  Party  (Purchaser) 

TO  Message  To 

N102  93  Name  C  AN  1/35 

Free-form  name. 


Conditional 


Conditional 


N103  66  Identification  Code  Qualifier  C  ID  1/2 

Code  designating  the  system/method  of  code  structure  used  for  Identification 
Code  (67). 

10  Department  of  Defense  Activity  Address  Code  (DODAAC) 

33  Commercial  and  Government  Entity  (CAGE) 

N104  67  Identification  Code  C  AN  2/17 

Code  identifying  a  party  or  other  code. 
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DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003030DOD 


841 • RESPONSE 
N2  •  ADDITIONAL  NAME  INFORMATION 


Optional 


Segment:  N2  Additional  Name  information 
Level:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  2 

Purpose:  To  specify  additional  names  or  those  longer  than  35  characters  in  length 


Implementation  Note: 

Use  of  this  segment  is  not  necessary  when  the  entity  cited  in  NlOl  is  described  by  use  of  a  CAGE 
code  or  a  DoDAAC. 


Mandatory 


Optional 


Data  Element  Summary 


MP. 

ots. 

DATA 

CLfMEMT 

NAMf 

ATHHSUTES 

N201 

93 

Name 

Free-form  name. 

M 

AN 

1/35 

N202 

93 

Name 

Free-form  name. 

O 

AN 

1/35 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841 • RESPONSE 

N3  •  ADDRESS  INFORMATION 


ANSI  ASC  X12  VERSiON/RELEASE  00303000D_ 


Segment:  N3  Address  Information 
Level:  Header 
Loop:  SPI/N1 

Optional  I  I  Usage:  Optional 

Max  Use:  2 

Purpose:  To  specify  the  location  of  the  named  party 

Implementation  Note: 

Use  of  this  segment  is  not  necessary  when  the  entity  cited  in  NlOl  is  described  by  use  of  a  CAGE 
code  or  a  DoDAAC. 


Mandatory 

Optional 


Data  Element  Summary 


MF. 

DCS. 

DATA 

CLIMDfr 

NAM€ 

ATTfUBUTCS 

N301 

166 

Address  Information 

Address  information 

M 

AN 

1/35 

N302 

166 

Address  Information 

Address  information 

O 

AN 

1/35 

13 


DC19>  JULY91993 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003030DOD 


841  •  RESPONSE 
N4  •  GEOGRAPHIC  LOCATION 


Optioiwl 


Segment:  N4  Geographic  Location 
Level:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  1 


Purpose:  To  specify  the  geographic  place  of  the  named  party 

Syntax:  1.  R01 05  —  At  least  one  of  N401  or  N405  is  required. 

2.  P0506  —  If  either  N405  or  N406  is  present,  then  the  other  is  required. 

Comments:  1.  A  combination  of  either  N401  through  N404  (or  N405  and  N406)  may 
be  adequate  to  specify  a  location. 


2.  N402  is  required  only  if  city  name  (N401 )  is  in  the  USA  or  Canada. 
Implementation  Note: 

Use  of  this  segment  is  not  necessary  when  the  entity  cited  in  NIOI  is  described  by  use  of  a  CAGE 
code  or  a  DoDAAC. 


Conditional 

Optional 

Optional 

Optional 

Conditional 

Conditional 


Data  Element  Summary 


REP. 

PCS. 

DATA 

BLEMCNT 

NAME 

ATTRIPUTtS 

N46i 

19 

CHy  Name 

Free-form  text  for  city  name. 

C 

AN 

2/30 

N402 

1S6 

State  or  Province  Code  0  ID  2/2 

Code  (Standard  State/Province)  as  defined  by  appropriate  government  agency. 

N403 

116 

Postal  Code  O 

Code  defining  international  postal  zone  code  excluding  punctuation 
(zip  code  for  United  States). 

ID 

and 

3/9 

blanks 

N404 

26 

Country  Code 

Code  identifying  the  country. 

0 

ID 

2/3 

N405 

309 

Location  Qualifier 

Code  identifying  type  of  location. 

c 

ID 

1/2 

N406 

310 

Location  Identifier 

Code  which  identifies  a  specific  location. 

c 

AN 

1/25 

OC19- JULY91993 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841 • RESPONSE 

PER  •  ADMINISTRATIVE  COMMUNICATIONS  CONTACT 


ANSI  ASC  X12  VERSION/RELEASE  003030000_ 


Optional 


Segment:  PER  Administrative  Communications  Contact 
Level:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  identify  a  person  or  office  to  whom  administrative  communications 
should  be  directed 

Syntax:  1.  P0304  —  If  either  PER03  or  PER04  is  present,  then  the  other  is 
required. 

2.  P0506  —  If  either  PER05  or  PER06  is  present,  then  the  other  is 
required. 


Mandatory 


Optional 


_ Data  Element  Summary _ 

REF.  DATA  .  „ 

OtS.  ELilllKT  NAME  _  ATTWMIvmS _ 

PER01  366  Contact  Function  Code  M  ID  2/2 

Code  identifying  the  major  duty  or  responsibility  of  the  person  or  group  named. 

1C  Information  Contact 
Code  Value  Implementation  Note: 

Use  Code  1C  for  the  information  contact  at  the  organization  providing  the  data. 

PER02  93  Name  O  AN  1/35 

Free-form  name. 

Implementation  Note: 

Use  to  provide  the  name  of  the  irformation  point  of  contact. 


Conditional 


PER03  365  Communication  Number  Qualifier 

Code  identifying  the  type  of  communication  number. 

Implementation  Note: 

Use  any  appropriate  code  although  Code  EM  is  preferred. 

EM  Electronic  Mail 
FX  Facsimile 
TE  Telephone 
TM  Telemail 


C  ID  2/2 


Conditional 


Conditional 


Conditional 


PER04  364 

PER05  365 

PER06  364 


Communication  Number  C  AN 

Complete  communications  number  including  country  or  area  code  when 
applicable. 

Communication  Number  Qualifier  C  ID 

Code  identifying  the  type  of  communication  number. 

Communication  Number  C  AN 

Complete  communications  number  including  country  or  area  code  when 
applicable. 


1/25 


2/2 

1/25 
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DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003030DO0_ 


Mandatary 


Segment:  HL  Hierarchical  Level 
Level:  Detail 
Loop:  HL  Repeat:  >1 
Usage:  Mandatory 
Max  Use:  1 


841 • RESPONSE 
HL  •  HIERARCHICAL  LEVEL 


Purpose:  To  identify  dependencies  among  and  the  content  of  hierarchically  related 
groups  of  data  segments. 

Comments:  1.  The  HL  Segment  is  used  to  identify  levels  of  detail  information  using  a 
Hierarchical  Structure,  such  as  relating  line  item  data  to  shipment  data, 
and  packaging  data  to  line  item  data. 

2.  The  HL  segment  defines  a  top-down/left-right  ordered  stnjcture. 

3.  HL01  shall  contain  a  unique  alphanumeric  number  for  each 
occurrence  of  the  HL  segment  in  the  transaction  set.  For  example  HL01 
could  be  used  to  indicate  the  number  of  occurrences  of  the  HL  segment, 
in  which  case  the  value  of  HL01  would  be  "1"  for  the  initial  HL  segment, 
and  would  be  incremented  by  one  in  each  subsequent  HL  segment 
within  the  transaction. 


4.  HL02  identifies  the  Hierarchical  ID  Number  of  the  HL  segment  to 
which  the  current  HL  segment  is  subordinate. 

5.  HL03  indicates  the  context  of  the  series  of  segments  foltowing  the 
current  HL  segment  up  to  the  next  occurrence  of  an  HL  segment  in  the 
transaction.  For  example,  HL03  is  used  to  indicate  that  subsequent 
segments  in  the  HL  loop  form  a  logical  grouping  of  data  referring  to 
shipment,  order  or  item  level  information. 

6.  HL04  indicates  whether  or  not  there  are  subordinate  (or  child)  HL 
segments  related  to  the  current  HL  segment. 

Implementation  Notes: 

1.  The  HL  loop  can  be  used  to  provide  a  response  to  a  request  for  a  single  specification  or  item  of 
technical  irformation  as  well  as  for  multiple  items  that  may  or  may  not  have  a  hierarchical 
relationship. 

2.  When  providing  a  single  specification  or  item  of  technical  information,  only  one  iteration  cf  the 
HL  loop  is  necessary. 

3.  When  providing  multiple  specifications  or  items  of  technical  information  that  may  or  may  not 
have  a  hierarchical  relationship,  repeat  the  HL  loop  as  many  times  as  required  to  specify  all  levels 
and  use  as  many  iterations  of  the  HL/SPI  loop  as  necessary. 

4.  When  SPI07  is  Code  08,  the  ONLY  entries  in  the  Detail  level  (Table  2)  are  in  HLOl  and  HL03. 


Mandatory 


_ Data  Element  Summary _ 

HEF.  DAT* 

PES  EI.EMEWT  NAME _ ATmmffES 

HLOl  628  Hierarchical  ID  Number  M  AN  1/12 

A  unique  number  assigned  by  the  sender  to  identify  a  particular  data  segment  in 
a  hierarchical  structure. 
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841  •  RESPONSE 

HL  •  HIERARCHICAL  LEVEL 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


Optional 


Mandatory 


Optional 


ANSI  ASC  X12  VERSION/RELEASE  003030DOD_ 

Imptomentation  Note: 

This  is  a  unique  and  progressive  number  assigned  by  the  originator  of  the  transaction  set  starting  with  the 
number  1 . 

HL02  734  Hierarchical  Parent  ID  Number  O  AN  1/12 

Identification  number  of  the  next  higher  hierarchical  data  segment  that  the  data 
segment  being  described  is  subordinate  to. 

Implementation  Note: 

This  data  element  is  used  only  when  providing  multiple  specifications  or  items  of  technical  information  that 
have  a  hierarchical  relationship. 

HL03  735  Hierarchical  Level  Code  M  ID  1/2 

Code  defining  the  characteristic  of  a  level  in  a  hierarchical  structure. 

Implementation  Note: 

Use  any  appropriate  listed  code  to  indicate  the  hierarchical  relationship  of  the  data  being  provided. 

A  Assembly 
F  Component 
I  Item 

Code  Value  Implementation  Note: 

Use  Code  I  as  a  default  code  when  no  other  code  is  applicable. 

SY  System 
U  Subassembly 
ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  ZZ,  only  when  SPI07  is  Code  08.  This  is  required  to  comply  with  the  mandatory  nature  of 
this  data  element. 

HL04  736  Hierarchical  Child  Code  O  ID  1/1 

Code  indicating  whether  if  there  are  hierarchical  child  data  segments  subordinate 
to  the  level  being  described. 

Implementation  Note: 

When  providing  single  or  multiple  specificationsi technical  information  that  have  no  hierarchical  relationship, 
no  entry  is  required. 

0  No  Subordinate  HL  Segment  in  This  Hierarchical  Structure. 

Code  Value  Implementation  Note: 

Use  Code  0  to  indicate  the  lowest  level  in  the  hierarchical  relationship. 

1  Additional  Subordinate  HL  Data  Segment  in  This  Hierarchical  Structure. 

Code  Value  Implementation  Note: 

Use  Code  I  to  indicate  there  are  lower  level  items  in  this  hierarchical  relationship. 


17 


DC19  •  JULY  9  1993 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


A»»l  ASC  X12  VERSION/RELEASE  003030DOD 


841  •  RKPONSE 
SPI  •  SPECIRCATION  IDENTIFIER 


Optional 


Segment:  SPi  Specification  Identifier 
Level:  Detail 

Loop:  HL/SPI  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  provide  a  description  of  the  included  specification  or  technical  data 
items. 

Data  Element  Summa 


Mandatory 


Mandatory 


Mandatory 


Optional 


SPI01  786  Security  Level  Code  M  ID  212 

Code  irKlicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  any  code. 

2.  If  the  data  item  being  transmitted  has  both  a  government  security  classification  and  a  commercial  security 
protection  requirement,  then  this  data  element  will  carry  the  government  security  classification  code  and  the 
commercial  security  protection  code  will  be  carried  in  SPI09. 

3.  If  the  data  item  being  transmitted  has  only  one  protection  requirement,  then  this  data  element  can  carry 
either  the  government  security  classification  or  the  commercial  security  protection  code. 


SPI02  128  Reference  Number  Qualifier  M  ID 

Code  qualifying  the  Reference  Number. 

Implementation  Note: 

Any  code  may  be  used  but  the  following  codes  are  typically  used: 

DD  Document  Identification  Code 
Code  Value  Implementation  Note: 

Use  Code  DD  for  the  reference  number  of  an  Engineering  Data  List. 

DG  Drawing  Number 

QC  Product  Specificatbn  Document  Number 

51  Engineering  Specification  Number 

52  Military  Specification  Number  (MILSPEC) 

53  Specification  Number 

TP  Test  Specification  Number 
W9  Special  Packaging  Instruction  Number 
ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  7Z  for  another  type  of  reference  number  and  identify  then  number  in  SPI04. 

SPI03  127  Reference  Number  M  AN 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 


M  ID 


SPI04 


Entity  Title 

Title  of  the  data  entity. 


O  AN  1/132 
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DEPARTMBfT  OF  DEFENSE 
DRAFT  niPLEMENTATION  CONVENTION 


841  •  RESPONSE 

SPI .  SPECIFICATION  IDENTIFIER  ANSI  ASC  X12  VERSiON/RELEASE  003030DOD 


NotUswl 

OptioMi 


Not  Used 
Not  Used 
Optional 


Not  Used 
Not  Uaad 
Not  Used 


Implenwntation  Note: 

When  SP102  is  Code  ZZ,  identify  the  reference  number  cited  in  SPI03. 

SPI05  791  Entity  Purpose  O  AN  1/80 

SPI06  792  Entity  Status  Code  O  ID  1/1 

Code  indicating  the  current  status  of  the  data  item  specified  by  the  electronic 
data  item. 

Implementation  Note: 

Use  any  code. 

Z  Mutually  Defined 

Code  Value  Implementation  Note: 

Use  Code  Z  for  another  entity  status  condition  and  explain  in  the  MSG  segment. 


SPI07 

353 

Transaction  Set  Purpose  Code 

O 

ID 

2/2 

SPI08 

755 

Report  Type  Code 

0 

ID 

2/2 

SPI09 

786 

Security  Level  Code 

O 

ID 

2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 


Implementation  Note: 

Use  this  data  element  ONLY  when  SP/OJ  is  Code  90,  92,93,  94,  or  99,  and  the  data  item  being  provided  also 
has  a  commercial  security  protection  requirement. 

00  Company  Non-ClassHied 
01  Company  Internal  Use  Only 
02  Company  Confidential 

03  Company  Confidential,  Restricted  (Need  to  Know) 

04  Company  Registered  (Signature  Required) 

05  Personal 

09  Company  Defined  (Trading  Partner  Level) 


SPI10 

559 

Agency  Qualifier  Code 

O 

ID 

2/2 

SPI11 

916 

Code  List  Reference 

0 

AN 

1/6 

SPI12 

554 

Assigned  Number 

0 

NO 

1/6 
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841  •  RESPONSE 

UN  •  rrEM  IDENT1RCATION 


DEPARTMENT  OF  OEFB4SE 
DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/REUEASE  00303000D 


Optional 


Segment:  LIN  Item  Identification 
Level:  Detail 
Loop:  HUSPI 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  specify  basic  item  identification  data. 

Syntax:  1.  C0405  —  If  LIN04  is  present,  then  LINOS  is  required. 

2.  C0607  —  If  LIN06  is  present,  then  LIN07  is  required. 

3.  C0809  —  If  LINOS  is  present,  then  LINOS  is  required. 

4.  C101 1  —  If  LIN10  is  present,  then  LIN1 1  is  required. 

5.  C1213  —  If  LIN12  is  present,  then  LIN13  is  required. 

6.  C1415  —  If  LIN14  is  present,  then  LIN15  is  required. 

7.  C1 61 7  —  If  LIN16  is  present,  then  LIN1 7  is  required. 

8.  C1819  —  If  LIN18  is  present,  then  LIN19  is  required. 

9.  C2021  —  If  LIN20  is  present,  then  LIN21  is  required. 

10.  C2223  —  If  LIN22  is  present,  then  LIN23  is  required. 

11.  C2425  —  If  LIN24  is  present,  then  LIN25  is  required. 

12.  C2627  —  If  LtN26  is  present,  then  LIN27  is  required. 

13.  C2829  —  If  LIN28  is  present,  then  LIN29  is  required. 

14.  C3031  —  If  LIN30  is  present,  then  LIN31  is  required. 

Semantic:  LIN01  is  the  line  Hern  identification 

Comments:  1.  See  the  Data  Dictionary  for  a  complete  list  of  ID  s. 

2.  LIN02  through  LIN31  provide  for  fifteen  (1 5)  different  product/service 
ID'S  for  each  item.  For  Example;  Case.  Cotor,  Drawing  No.,  UPC  No., 
ISBN  No..  Model  No.,  SKU. 

Implementation  Notes: 

1.  Use  this  segment  to  transmit  information  relative  to  the  data  item  identified  in  SPI03,  e.g., 
national  stock  number  (NSN),  manifacturer' s part  number,  item  description,  etc.. 

2.  LIN02  through  UN 31  are  used  in  pairs  (i.e.,  UN02  and  IJN03)  as  required  to  carry  additional 
information  about  the  specific  data  item  in  SPI03. 


_ Data  Element  Summary _ 

REF.  DATA 

OES.  ELEMEWT  NAME _ ATmfVTES 


NotUaed  LIN01  350  Assigned  Identification  O  AN  1/11 

Mandatory  LIN02  235  Product/Service  ID  Qualifier  M  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

F7  End-Item  Description 
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Code  Value  Implementation  Note: 

Use  Code  F7  for  the  application  reference  frimi  an  Engineering  Data  List 

FS  National  Stock  Njmber 
Code  Value  Implementation  Note: 

Use  Code  FS  for  the  Naltunal  Stock  Number. 

IN  Buyer's  Item  Number 

Code  Value  Implementation  Note: 

Use  Code  IN  for  the  CLIN  oc  SUBCLIN 

MG  Manufacturer’s  Part  Number 

Code  Value  Implementation  Note: 

Use  Code  MG  for  a  manufacturer’s  part  number. 

PD  Part  Number  Description 

Code  Value  Implementation  Note: 

Use  Code  PD  for  the  noun  description  from  an  Engineering  Data  List. 

ZZ  Mutually  Defined 

Code  Value  Implementation  Note: 

Use  Code  ZZ  for  the  Data  Tech  orginization  from  an  Engineering  Data  List. 

Mandatory  LINOS  234  Product/Service  ID  M  AN 

Identifying  number  for  a  product  or  service. 

Optional  LIN04  235  Product/Servica  ID  Qualifier  O  ID 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

Conditional  LINOS  234  Product/Service  ID  C  AN 

Identifying  number  for  a  product  or  service. 

Optional  LIN06  235  Product/Service  ID  Qualifier  O  ID 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

Conditional  LIN07  234  Product/Service  ID  C  AN 

Identifying  number  for  a  product  or  service. 

Optional  LINOS  235  Product/Service  ID  Qualifier  O  ID 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

Conditional  LINOS  234  Product/Service  ID  C  AN 

Identifying  number  for  a  product  or  service. 

Optional  LIN 10  235  Product/Service  ID  Qualifier  O  ID 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

Conditional  LIN11  234  Product/Service  ID  C  AN 

Identifying  number  for  a  product  or  service. 

Optional  LIN12  235  Product/Service  ID  Qualifier  O  ID 

Code  identifying  the  type/source  of  the  descriptive  number  used  ir 
Product/Service  ID  (234). 

Conditional  LIN 13  234  Product/Service  ID  C  AN 


1/30 

2/2 

1/30 

2/2 

1/30 

2/2 

1/30 

2/2 

1/30 

2/2 

1/30 
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Identifying  number  for  a  product  or  service. 

Optional 

LIN14 

235 

ProductyService  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN15 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

j 

j 

LIN16 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN17 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

! 

1 

LIN18 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN19 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN20 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN21 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN22 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/scurce  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN23 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN24 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

212 

Conditional 

LIN25 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN26 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

212 

Conditional 

LIN27 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LfN28 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN29 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 
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Conditional  LIN31 


235  Product/Service  ID  Qualifier  O  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

234  Product/Service  ID  D  AN  1/30 

Identifying  number  for  a  product  or  ser  /ice. 
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Optional 


Mandatory 


Conditional 


Conditional 


Conditional 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 
Symax: 


N1  Name 

Detail 

HUSPI 

Optional 

>1 


To  identify  a  party  by  type  of  organization,  name  and  code 

1.  R0203  —  At  least  one  of  N 102  or  N 103  is  required. 

2.  P0304  —  If  either  N1 03  or  N1 04  is  present,  then  the  other  is  required. 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  "ID 
Code"  (N104)  must  provide  a  key  to  the  table  maintained  by  the 
transaction  processing  party. 


_ Data  Element  Summary _ 

ntP.  DATA 

Qgs.  cmwwr  wamb  atth*  tins 

N101  98  Entity  Identifier  Code  M  ID  2/2 

Code  identifying  an  organizational  entity,  a  physical  location,  or  an  individual 

33  Inquiry  Address 
Code  Value  Implementation  Note: 

Use  Cade  33  to  identify  a  Data  Tech  entity  from  an  Engineering  Data  List. 

ZE  End  Item  Manufacturer 
Code  Value  Implementation  Note: 

Use  Code  ZE  to  identify  the  manufacturer  from  an  Engineering  Data  List. 


N102 

93 

Name 

Free-form  name. 

C 

AN 

1/35 

N103 

66 

Identification  Code  Qualifier 

C 

ID 

1/2 

Code  designating  the  system/method  of  code  structure  used  for  Identification 
Code  (67). 

10  Department  of  Defense  Activity  Address  Code  (DODAAC) 

33  Commercial  and  Government  Entity  (CAGE) 

N104  67  Identification  Code  C  AN  2/17 

Code  identifying  a  party  or  other  code. 
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MSG  •  MESSAGE  TEXT 


Optional 


Segment:  MSG  Message  Text 
Level:  Detail 
Loop:  HL/SPI 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  provide  a  free  form  format  that  would  allow  the  transmission  of  text 
information. 

Comment:  MSG02  is  not  related  to  the  specific  characteristics  of  a  printer,  but 
identifies  top  of  page,  advance  a  line,  etc. 

Implementstion  Notes: 

1.  Use  this  segment  to  provide  information  relative  to  a  specific  data  item. 

2.  Maximum  use  is  3 . 


Mandatory 

Not  Uaad 


Data  Element  Summary 

MF. 

DCS. 

DATA 

CLIMM 

NMIC 

ATTRiftirTtS 

MSG01 

933 

Free-Form  Message  Text 

Free-form  message  text. 

M  AN  1/264 

MSG02 

934 

Printer  Carriage  Control  Code 

O  ID  2/2 

DC19>  JULY91993 
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Optional 


Segment:  PID  Product/ltem  Description 
Level:  Detail 

Loop:  HL/PID  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 


Purpose:  To  describe  a  product  or  process  in  coded  or  tree-form  format 
Syntax:  1.  C0403  —  If  PID04  is  present,  then  PID03  is  required. 

2.  R0405  —  At  least  one  of  PID04  or  PID05  is  required. 

3.  C0703  —  If  PID07  is  present,  then  PID03  is  required. 

4.  C0803  —  If  PID08  is  present,  then  PiD03  is  required. 


Semantic:  1.  Use  PID03  to  indicate  the  organization  that  publishes  the  code  list 
being  referred  to. 

2.  PIO04  Should  be  used  for  industry-specific  product  description  codes. 

3.  PID08  describes  the  physical  characteristics  of  the  product  identified 
in  PID04.  A  “Y"  indicates  that  the  specified  attribute  applies  to  this  item. 
A  “N"  indicates  it  does  not  apply.  Any  other  value  is  irideterminate. 

Commerns:  1.  If  PID01  =  “F",  then  PID05  is  used.  If  PID01  =  “S”,  then  PID04  is 
used.  If  PID01  =  “X".  then  both  PID04  and  PID05  are  used. 


2.  Use  PID06  when  necessary  to  refer  to  the  product  surface  or  layer 
being  described  in  the  segment. 

3.  PIO07  specifies  the  individual  code  list  of  the  agency  specified  in 
PID03. 


Implementation  Note: 

Use  this  segment  when  the  PWK  segment  is  needed  to  describe  how  the  requested 
specifications!  technical  information  is  being  sera  if  it  is  not  provided  in  the  BIN  segment  of  this 
transaction  set. 


Mandatory 


Not  Uaad 
Not  Used 
Not  Used 
Conditional 


_ Data  Element  Summary _ 

REF.  ORTA 

OtS.  ELEMEKT  NAME _ _ _ ATmUUTES 

PID01  349  Kern  Description  Type  M  ID  1/1 

Code  indicating  the  format  of  a  description. 

F  Free-form 

Code  Value  Implementation  Note: 

Use  Code  F  to  indicate  a  free-form  description  follows  in  FIDOS. 


PID02 

750 

Product/Process  Characteristic  Code 

O 

ID 

2/3 

PID03 

559 

Agency  Qualifier  Code 

C 

ID 

2/2 

PID04 

751 

Product  Description  Code 

C 

AN 

1/12 

PID05 

352 

Description 

C 

AN 

1/80 

A  free-form  description  to  clarify  the  related  data  elements  and  their  content. 
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NotUMd 
Not  UMd 
Not  Used 


Implementation  Notes: 

1.  When  all  the  requested  items  will  be  sent  by  the  same  media,  other  than  in  the  current  841  transaction  set, 
enter  the  words  "All  Data  -  See  PWK  Segment  " 

2.  When  a  specific  data  item  or  file  will  not  be  provided  in  the  BIN  segment  of  this  transaction  set  but  will  be 
sera  by  some  other  media  specified  in  the  PWK  segment,  use  this  data  elemerU  to  idemify  the  data  item  or  file. 

PID06  752  Surface/Layer/Position  Code  O  ID  212 

PID07  822  Source  Subqualifier  O  AN  1/15 

PID08  1073  Yes/No  Condition  or  Response  Code  O  ID  l/l 


DC19  •  JULY  9  1993 
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Segment:  PWK  Paperwork 
Level:  Detail 
Loop:  HL/PID 
Usage:  Optional 
Max  Use:  >1 


ANSI  ASC  X12  VERSION/RELEASE  003030000_ 


Purpose:  To  identify  the  type  and  transmission  of  paperwork  or  supporting 
information 

Syntax:  P0506  —  If  either  PWK05  or  PWK06  is  present,  then  the  other  is 
required. 

Comments:  1.  PWK05  and  PWK06  may  be  used  to  identify  the  addressee  by  a  code 
number. 


2.  PWK07  may  be  used  to  indicate  special  information  to  be  shown  on 
the  specified  report. 

3.  PWK08  may  be  used  to  indicate  action  pertaining  to  a  report. 
Implementation  Note: 

Use  this  segment  only  if  all  the  requested  data  are  not  being  provided  in  the  BIN  segment  of  this 
transaction  set. 


Mandatory 


Optional 


Not  Used 
Not  Used 
Not  Used 
Not  Used 
Not  Used 
Not  Used 


_ Data  Element  Summary _ 

Mr.  DATA 

ots.  tLimm  wmt  athmsi/tm 

PWK01  755  Report  Type  Code  M  ID  2/2 

Code  irKficating  the  title  or  contents  of  a  document,  report  or  supporting  item 

SP  Specification 

Code  Value  Implementation  Note: 

Use  Code  SP  to  indicate  Specificatiorts/T echnical  Information. 

PWK02  756  Report  Transmission  Code  O  ID  2/2 

Code  defining  timing,  transmission  method  or  format  by  which  reports  are  to  be 
sent 

BM  By  Mail 
FX  By  Fax 


PWK03 

757 

Report  Copies  Needed 

0 

NO 

1/2 

PWK04 

98 

Entity  Identifier  Code 

O 

ID 

2/2 

PWK05 

66 

Identification  Code  Qualifier 

C 

ID 

1/2 

PWK06 

67 

Identification  Code 

C 

AN 

2/17 

PWK07 

352 

Description 

0 

AN 

1/80 

PWK08 

704 

Paperwork/Report  Action  Code 

0 

ID 

1/2 
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Segment:  EFI  Electronic  Format  Identification 
Level:  Detail 

Loop:  HUEFI  Repeat:  >1 


Optional 


Usage:  Optional 
Max  Use:  1 

Purpose:  To  provide  basic  information  about  the  electronic  format  of  the 
interchange  data. 

Syntax:  1.  C0504  —  If  EFI05  is  present,  then  EFI04  is  required. 

2.  C0706  —  If  EFI07  is  present,  then  EFI06  is  required. 

3.  C0908  —  If  EFI09  is  present,  then  EFI08  is  required. 


Implementation  Note: 

Maximum  use  is  I  for  each  HL. 


Mandatory 


Optional 


_ Data  Element  Summary _ 

REF.  ORTA 

PIS.  ELIMEMT  HAME _ ATIRIRUTIS 

EFI01  786  Security  Level  Code  M  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  any  appropriate  code. 

2.  The  security  level  code  specified  here  relates  to  the  specific  binary  data  provided  in  the  BIN  segment. 

3.  The  security  code  provided  for  the  binary  data  being  transmitted  in  the  BIN  segment  is  the  highest 
protection  level  assigned  to  the  data.  If  the  data  have  both  a  government  security  classification  and  a 
commercial  security  protection  requirentera,  the  government  security  classification  takes  precedence  and 
must  be  provided  in  this  data  element. 

EFI02  933  Free-Form  Message  Text  O  AN  1/264 

Free-form  message  text. 

Implementation  Note: 

Use  only  if  necessary  to  transmit  a  short  remark  about  the  binary  data  being  provided. 


Optional 


EFI03  797  Security  Technique  Code  O  ID  2/2 

Lode  indicating  that  this  elerrer.t  will  be  used  to  tell  an  EDI  translator  program 
which  security  tehnique  to  use. 

Implementation  Note: 

Use  any  code. 


Conditional 


EFI04  799  Version  Identifier  C  AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm. 

Implementation  Note: 

Use  to  specify  the  version,  e.g.,  2.0, 3.2,  etc.,  of  the  program  being  used  to  transmit  the  data  in  the  following 
BIN  segment.  This  data  element  pertains  to  the  program  identifier  specified  in  EF105. 


Optional 


EFI05  802  Program  Identifier  O  AN  1/30 

Identifies  the  name  of  the  software  program  from  which  the  technical  data 
originates. 
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Impletmntation  Note: 

Use  to  specify  the  application  software  program  used  to  create  the  data  being  transmitted  in  the  following 
BIN  segment,  e.g.,  TruckCad,  ClassSCad.  etc. 

Conditional  EFI06  799  Version  Identifier  C  AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm. 

Implementation  Note: 

Use  to  identify  the  specific  version  of  the  interchange  standard  used  to  transmit  the  data  in  the  following  BIN 
segment.  This  data  element  pertains  to  the  interchange  format  specified  in  EFI07. 

Optional  EFI07  801  Interchange  Format  O  AN  1/30 

industry  or  proprietary  standard  used  to  identify  the  format  of  the  data. 

Implementation  Note: 

Use  to  enter  the  specification  number  or  description  of  the  version  noted  in  EFlOb.  Examples  include  MIL-D- 
28000 for  IGES  and  MIL  R-28002 for  Raster. 

Conditional  EFI08  799  Version  Identifier  C  AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm. 

Implementation  Note: 

Use  to  identify  the  version  of  the  program  used  to  compress  the  data  transmitted  in  the  following  BIN 
segment.  This  data  element  pertains  to  the  compression  technique  program  specified  in  EFI09. 

Optional  EFI09  800  Compression  Technique  O  AN  1/30 

Identifies  the  digital  date  compression  means  and  the  type. 

Implementation  Note: 

Use  to  identify  the  compression  method,  if  any,  applied  to  the  data  transmitted  in  the  following  BIN  segmeru. 
Examples  include:  TR,  Moyer,  Fish,  etc.. 

Optional  EFIlO  789  Drawing  Sheet  Size  Code  O  ID  2/2 

Code  indicating  the  drawing  size  and  orientation  of  a  technical  drawing  as 
specified  and  described  in  the  current  version  of  standards  ANSI  Y14.1  and  ISO 
5457  (E).  See  the  listed  ANSI  and  ISO  standards  for  the  maximum  lengths  for 
rolled  sheets.* 

Implementation  Notes: 

1.  Use  to  specify  the  drawing  sheet  size  if  the  data  transmitted  in  the  BIN  segment  are  to  be  presemed  in  a 
hard  copy  as  well  as  stored  in  the  receiver's  system. 

2.  Use  any  code. 

Optional  EFI11  803  File  Name  O  AN  1/64 

Name  assigned  or  declared  for  a  file  or  used  by  a  program  to  identify  a  file.  Exact 
format  of  the  name  depends  on  the  computer  operating  system  being  used. 
Name  also  may  be  known  as  the  file's  "data  set  name”. 

Implementation  Note: 

Use  to  enter  the  file  name  of  the  data  item  being  transmitted. 


Not  Uaed 
Not  Used 
Not  Used 


EFI12  804  Block  Type 

EFI13  787  Record  Length 

EFI14  788  Block  Length 
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Segment:  BIN  Binary  Data 
Level:  Detail 
Loop:  HUEFI 
Usage:  Optional 
Max  Use:  >1 


841  •  RESPONSE 
BIN  •  BINARY  DATA 


Optional 


Purpose:  To  transfer  binary  data  in  a  single  data  segment  and  to  allow 

identification  of  the  end  of  the  data  segment  through  a  count.  There  is  no 
identification  of  the  internal  staicture  of  the  binary  data  in  this  segment. 

Data  Element  Summa 


Mandatory 


Mandatory 


BIN01  784  Length  of  Binary  Data 

The  length  in  integral  octets  of  the  binary  data. 


M  NO  1/15 


BIN02  785  Binary  Data  M  B  1/10 

A  string  of  octets  which  can  assume  any  binary  pattern  from  hexadecimal  00  to 
FF. 
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SE  •  TRANSACTION  SET  TRAILER  ANSI  ASC  X12  VERSION/RELEASE  003030DO0. 


Mandatory 


Mandatory 


Mandatory 


Segment:  SE  Transaction  Set  Trailer 
Level:  Summary 

Loop:  _ 

Usage:  Mandatory 
Max  Use:  1 

Purpose:  To  indicate  the  end  of  the  transactbn  set  and  provide  the  count  of  the 
transmitted  segments  (including  the  beginning  (ST)  and  ending  (SE) 
segments). 

Comment:  SE  is  the  last  segment  of  each  transaction  set. 


DATA 

CLCMIMr  NAW 


Data  Element  Summai 


ATT1l»UrtS 


SE01  96  Number  of  Included  Segments  M  NO  1/10 

Total  number  of  segments  included  in  a  transaction  set  including  ST  and  SE 
segments. 


SE02  329  Transaction  Set  Control  Number  M  AN  4/9 

Identifying  control  number  that  must  be  unique  within  the  transaction  set 
functional  group  assigned  by  the  originator  for  a  transaction  set 


Implementation  Note: 

Enter  the  same  number  as  carried  in  ST02. 
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4.0  ASC  X  12  FORMS 


In  this  chapter,  applicable  ASC  X12  forms  are  presented. 


4.0.2 
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ASC  XI 2  WORK  REQUEST  FORM 
SUBMITTER  INSTRUCTIONS 

NOTE:  ALL  REQUESTS  MUST  BE  TYPED  OR  PRINTED  LEGIBLY  IN  BLACK  INK. 
INCOMPLETE  OR  ILLEGIBLE  WORK  REQUESTS  WILL  BE  RETURNED  TO  THE 
SUBMITTER. 

Submit  completed  forms  to:  Technical  Department.  ASC  Xi2  Secretariat.  Data  Interchange  Standards  Association, 
Inc..  1800  Diagonal  Road.  Suite  355.  Alexandria.  VA  22314-2852  or  FAX  (703)  548*5738.  Submitters  are  notified  of 
the  status  of  the  work  request  after  it  has  been  reviewed  by  Xi2J  Technical  Assessment  Subcommittee. 

1.  TO  USE  THIS  FORM  TO  REQUEST  A  CHANGE  TO  AN  EXISTING  STANOARD(S),  use  ONE  Work  Request 
(WR)  Form  to  list  all  changes  needed  to  meet  one  BUSINESS  REASON.  Otherwise  use  muftipie  forma.  If  more 
space  is  necessary,  numbered  attachments  may  be  used  for  continuation. 

2.  TO  USE  THIS  FORM  FOR  SUPPORTING  DATA  MAINTENANCE  FOR  A  NEW  DRAFT  STANDARD,  list  all 
information  on  ONE  form;  use  attachments  as  necessary.  List  first  aU  new  segments,  then  all  new  data 
eiements/codes/code  sources.  Then  list  revisions  to  existing  segments  and  data  eiemants/codea/code  sources; 
provide  a  business  case  for  revisions  to  existing  starxlards.  Then  list  any  others  changes  n^ed  (e.g.,  X12.S. 

XI 2. 6).  including  justification. 

3.  TO  USE  THIS  FORM  TO  REQUEST  A  PROPOSED  NEW  X12  STANDARDS  PROJECT,  provide  the  business 
need  and  justification  for  the  new  project  In  Part  0.  The  WR  w8i  be  referred  to  an  X12  subcommJttee  for  anaiysia 

ADDITIONAL  INFORMATION  FOR  COMPLETING  THIS  FORM: 

PART  A:  SUBMITTER  INFORMATION:  The  WR  may  represent  the  position  of  an  Individual,  Industry  group,  work 
group.  X12  subgroup,  etc.  If  the  WR  represents  the  position  of  an  X12  subconvnittee-raiated  work  group,  the 
subcommittee  chair  must  initial  the  WR. 

PART  B:  REFERENCE  USED:  Indicate  the  version/reiease  or  edition  of  the  standard  you  are  using  as  a  reference. 

PART  C:  RAMIFICATIONS:  List  affected  transaction  sots,  segments  and  data  slemeres.  or  other  ttandards.  For  a 
control  standard,  name  the  affected  page  and  section  number. 

PART  D:  BUSINESS  CASE/REASON  FOR  CHANGE:  Provide  a  complete  scerwio  ttwt  describes  the  buslnsss 
function/operation  that  wfll  be  sadsfled  by  a  change  to  the  standard.  Be  specific,  because  this  Information  wB 
appear  in  the  X12  membership  ballot  package  and  wil  be  the  only  Information  that  members  have  on  which  to  base 
their  vote.  Xi  2 J  Technical  Assessment  Subcommittee  requires  enough  Information  to  be  able  to  propose  an 
alternate  solution  to  the  one  provided.  If  necessary. 

PART  E:  PROPOSED  WORK:  List  the  specific  changes  being  requested.  Give  the  names  and  assodatad 
identifiers  of  the  standards  segments,  data  elements  and  codes  affected  by  the  changes.  Definitions  for  new  codes 
and  for  industry-specific  terms  must  be  complete.  For  new  codes,  provide  a  proposed  code  and  a  code  defMtioa 
RULES:  (1)  Acronyms/abbreviations  cannot  be  added  to  the  standards-they  must  be  speHadouL  ^)PnNidean 
expanded  code  definition  for  each  code  that  Is  not  compieteiy  self  explanatory,  that  is,  terms  that  are  not  In  general 
business  use  or  that  are  industry  specific.  (3)  Provide  code  source  rsferancas  for  afl  axtamafly  publishad  (norvXt2) 
code  lists  cited  (use  the  Form  for  New  or  Revised  Code  Source  Reference,  page  2  of  the  form). 
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9/14/92 

Date  SubmiRad _ 

OM  NUMBER 

(Subminar  Provide) 

ASC  X12 

(Secretariat  Only) 

'VORK  REQUEST  FORM 


A.  SUBMITTER  INFORMATION: 

Subminer  Name _ _  Company 

Address  _ Address/ZlP  _ /ZIP  +4 

Phone _ _ 


Submission  rapresents  the  position  oh _ SC  Chair  IniUais: 


B.  REFERENCE  USED:  Version _ /Release _ /Subralease _ or  Workbook  (date). 


C.  RAMIFICATIONS: 

Transaction  Set(s)  Used 
Segment(s)  Affeaed 
Oau  Element(s)  Affected 
Other  Standard(s) 


0.  BUSINESS  CASE/REASON  FOR  CHANGE: 


E.  PROPOSED  WORK: 


BASEUNE  AS  OF:  JULY  9, 1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


Rr>.  9/14/U 
WR  Fonn  Piga  Two 


DM  NUMBER _ 

(Spcrsttrtat  Only) 


FORM  FOR  NEW  OR  REVISED  CODE  SOURCE  REFERENCE 
FOR  X12.3  DATA  ELEMENT  DICTIONARY 


INSTRUCTIONS:  Complete  this  form  whenever  a  new  dau  element  or  data  element  code  is  requested  to  be 
added  to  Appendix  A  of  X  72.3  Data  Element  Dictioneiy,  which  references  a  coda  list  published  by  an  organization 
external  to  X12.  Use  one  form  for  each  new  reference.  This  form  may  be  used  to  revise  currant  references:  fV  out 
the  appropriate  areas  below. 


PART  1 :  REFERENCE  Cirei*  i  ot  2  mow.  if  2,  fiu  in  tno  oionk. 


(1)  NEW  REFERENCE 

(2)  REVISED  REFERENCE.  Current  reference  number/name 


PART  2:  REFERENCE  TITLE  «ttMro«  only  onoaouico  tor  eodao  tor  «m  data  olamontewaSoeMuid  bo  ewtanMooSweeiB 
otomont  nomo.  if  maro  aro  muwpio  eodoo  rotoroneine  oitomal  eodo  oouieoa  tor  Sw  oonw  dan  olomont  SSo  meuM  oppratoiMto  tto  oodo 
doflnWon. 

REFERENCE  Tm£: 


PARTS:  DATA  ELEMENTS  USED  IN  Qiwo  an  dan  alamont  rotoronoo  number  and  nann  wnisn  dtacn  an  uaorn  avo  oedo 
Muroo.  Qivoaweodo!0(ifaaaienad)iiaiisiatoraapoGifleoodoofaiodattotomonL 

USED  IN:  DE  No. _ .  Code  ID _ 

PART  4:  SOURCE  Provtoo  aw  name  of  an  publlcaaon  which  eomnna  an  oodaoroloioncod. 

PUBUSHED  IN: 


PARTS:  AVAILABLE  FROM  Givoanpubllamr.oroanroeniacLfromwhemanuaareenoMalnendeeumanL 

AVAILABLE:  Name/Attn  of  _ 

Company  _ 

Addraaa  _ 

Addreaa  _ 

AddreM/ZIP  _ /ZIP  ♦  4 


PARTS:  ABSTRACT  Brtofly dooertbo an pubUcaSon, no purpooo, and indloato what oodoo R eomalna. 
ABSTRACT: 
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5.0  GLOSSARY 


This  chapter  contains  ASC  XI 2-  and  DoD-specific  glossaries. 

5.1  X12  GLOSSARY 

ANSI 

American  National  Standards  Institute 

ANSI  Standard 

A  document  published  by  ANSI  that  has  been  approved  through 
the  consensus  process  of  public  announcement  and  review.  Each 
such  standards  must  have  been  developed  by  an  ANSI  committee 
and  must  be  revisited  by  that  committee  within  S  years  for  updat¬ 
ing.  See  Draft  Standard  for  Trial  Use  (DSTU). 

Area  Transaction  Set 

A  predefined  area  within  a  transaction  set  (header,  detail,  sum¬ 
mary)  containing  segments  and  their  various  attributes. 

ASC  X12 

Accredited  Standards  Committee,  X12.  It  comprises  industry 
members  who  create  electronic  data  interchange  (EDI)  standards 
for  submission  to  ANSI  for  subsequent  approval  and  dissemination. 

Authentication 

A  mechartism  that  allows  the  receiver  of  an  electronic  transmission 
to  verify  the  sender  and  the  integrity  of  the  content  of  the  trans¬ 
mission  through  the  use  of  an  electronic  “key”  or  algorithm  shared 
by  the  trading  partners.  That  algorithm  is  sometimes  referred  to 
as  an  electronic  signature. 

Compliance  Checking 

A  checking  process  that  is  used  to  ensure  that  a  transmission 
complies  with  ANSI  X12  syntax  rules. 

Conditional  (C) 

A  data  element  requirement  designator  that  indicates  that  the 
presence  of  a  specified  data  element  is  dependent  on  the  value  or 
presence  of  other  data  elements  in  the  segment.  The  condition 
must  be  stated  and  must  be  conqiuter  processable. 

Control  Segment 

A  segment  that  has  the  same  structure  as  a  data  segment  but  is 
used  for  transferring  control  information  for  grouping  data  seg¬ 
ments.  Control  segments  may  be  loop  control  segments  (LS/LE), 
transaction  set  control  segments  (ST/SE),  or  functional  group  con¬ 
trol  segments  (GS/GE),  defined  in  X12.6,  or  interchange  control 
segments  (ISA/IEA/TAl)  defined  in  X12.S. 
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Data  Element 

The  basic  unit  of  information  in  the  EDI  sundards  containing  a 
set  of  values  that  represent  a  singular  fact.  It  may  be  single-char¬ 
acter  codes,  literal  descriptions,  or  numeric  values. 

Data  Element  Length 

The  range,  minimum  to  maximum,  of  the  number  of  character 
positions  available  to  represent  the  value  of  a  data  element.  A 
data  element  may  be  of  variable  length  and  range  from  minimum 
to  maximum  or  it  may  be  of  fixed  length  in  which  the  minimum 
is  equal  to  the  maximum. 

Data  Element  Reference  Number 

Number  assigned  to  each  data  element  as  a  unique  identifier. 
Data  Element  Requirement  Designator 

A  code  defining  the  need  for  a  data  element  value  to  appear  in  the 
segment  if  the  segment  is  transmitted.  The  X12  codes  are  man¬ 
datory  (M),  optional  (O),  or  conditional  (C).  DoD  may  consider 
a  segment  “mandatory”  even  through  it  is  “optional”  by  X12 
standards. 

Data  Element  Separator 

A  unique  character  preceding  eacu  data  element  that  is  used  to 
delimit  data  elements  within  a  segment.  DoD  uses  as  the 
delimiter. 

Data  Element  Type 

A  data  element  may  be  one  of  six  types;  numeric,  decimal, 
identifier,  string,  date,  or  time. 

Delimiters 

Two  levels  of  separators  and  a  terminator.  The  delimiters  are  an 
integral  part  of  the  transferred  data  stream.  They  are  specified  in 
the  interchange  header  and  may  not  be  used  in  a  data  element 
value  elsewhere  in  the  interchange.  From  highest  to  lowest  level, 
the  separators  and  terminator  are  segment  terminator  and  data 
element  separator. 

DISA 

Data  Interchange  Standards  Association.  A  nonprofit  organization 
funded  by  ASC  X12  members  to  serve  as  the  Secretariat  for  X12. 

DSTU 

Draft  Standard  for  Trial  Use.  It  represents  a  document  approved 
for  publication  by  the  full  X12  committee  following  memitership 
consensus  and  subsequent  resolution  of  negative  votes.  (Fin^ 
Report  of  X12  Publications  Task  Group).  The  Draft  EDI  Standard 
for  Trial  Use  document  represents  an  ASC  X12  approved  standard 
for  use  prior  to  approval  by  ANSI.  See  ANSI  Standard. 
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EDI 

Electronic  data  interchange.  The  computer-^plication-to-com- 
puter-application  exchange  of  business  information  in  a  standard 
format. 

Electronic  Envelope 

Electronic  information  that  binds  together  a  set  of  transmitted 
documents  being  sent  from  one  sender  to  one  receiver. 

Element  Delimiter 

A  single-character  that  follows  the  segment  identifier  and  separates 
each  data  element  in  a  segment  except  the  last. 

Functional  Group 

A  group  of  one  or  more  transaction  sets  bounded  by  a  functional 
group  header  segment  and  a  functional  group  trailer  segment. 

Functional  Group  Segments  (GS/GE) 

These  segments  identify  a  specific  functional  group  of  documents 
such  as  purchase  orders. 

Industry  Conventions 

Defines  how  the  ASC  X12  standards  are  used  by  the  specific 
industry 

Industry  Guidelines 

Defines  the  EDI  environment  for  using  conventions  within  an 
industry.  It  provides  assistance  on  how  to  inqilement  XI 2  stand¬ 
ards. 

Interchuige  Control  Segments  (ISA/IEA) 

These  segments  identify  a  unique  interchange  being  sent  from  one 
sender  to  one  receiver  (see  electronic  envelope). 

Interchange  Control  Structure 

The  interchange  header  and  trailer  segments  that  envelop  one  or 
more  functional  groups  or  interchange-related  control  segments  and 
perform  the  following  functions;  (1)  defines  the  data  element 
separators  and  the  data  segment  terminators,  (2)  identifies  the 
sender  and  receiver,  (3)  provides  control  information  for  the  inter¬ 
change,  and  (4)  allows  for  authorization  and  security  information. 
(XI  2.5) 

Loop 

A  group  of  semantically  related  segments;  these  segments  may  be 
either  bounded  or  unbounded  (X12.6).  The  N1  loop  is  an  example 
of  a  loop,  which  includes  Segments  N1  to  PER  for  name  and 
address  information. 

Mandatory  (M) 

A  data  element/segment  requirement  designator  that  indicates  the 
presence  of  a  specified  data  element  is  required. 
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Mapping 

The  process  of  identifying  the  standard  data  element's  relationship 
to  application  dau  elements. 

Max  Use 

Specifies  the  maximum  number  of  times  a  segment  can  be  used  at 
the  location  in  a  transaction  set 

Message 

Entire  data  stream  including  the  outer  envelope 
Optional  (O) 

A  data  element/segment  requirement  designator  that  indicates  the 
presence  of  a  specified  data  element/segment  is  at  the  option  of 
the  sending  party  and  can  be  based  on  the  mutual  agreement  of 
the  interchange  patties. 

Qualifier 

A  data  element  that  identifies  or  defines  a  related  element,  set  of 
elements,  or  a  segment.  The  qualifier  contains  a  code  taken  from 
a  list  of  approved  codes. 

Repeating  Segment 

A  segment  that  may  be  used  more  than  once  at  a  given  location 
in  a  transaction  set.  See  Max  Use. 

Security 

System  screening  that  denies  access  to  unauthorized  users  and 
protects  data  from  unauthorized  uses 

Segment 

Segments  consist  of  logically  related  data  elements  in  a  defined 
sequence.  A  data  segment  consists  of  a  segment  identifier,  one  or 
more  data  elements  each  preceded  by  an  element  separator,  and 
a  segment  terminator. 

Segment  Directory 

Provides  the  purpose  and  format  of  the  segments  used  in  the 
construction  of  transaction  sets.  The  directory  lists  each  segment 
by  name,  purpose,  identifier,  the  contained  data  elements  in  the 
specified  order,  and  the  requirement  designator  for  each  data 
element. 

Segment  Identifier 

A  unique  identifrer  for  a  segment,  consisting  of  a  combination  of 
two  or  three  upper-case  letters  and  digits.  The  segment  identifier 
occupies  the  first-character  positions  of  the  segment  It  is  not  a 
data  element  The  segment  identifier  in  EDIT  ACT  is  a  component 
data  element  —  part  of  a  composite  data  element  consisting  of  a 
segment  identifier  and  an  explicit  looping  designator. 
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Segment  Terminator 

A  unique  character  appearing  at  the  end  of  a  segment  to  indicate 
the  termination  of  the  segment,  e.g.,  N/L. 

Syntax 

The  grammar  or  rules  that  define  the  structure  of  the  EDI  standards 
(i.e.,  the  use  of  loops,  qualifiers,  etc.).  Syntax  rules  are  published 
in  ANSI  X12.6. 

Transaction  Set 

A  document  that  unambiguously  defines,  in  the  standard  syntax, 
information  of  business  or  strategic  significance  and  consists  of  a 
header  segment,  one  or  more  data  segments  in  a  specified  order, 
and  a  trailer  segment. 

Transaction  Set  ID 

An  identifier  that  uniquely  identifies  the  transaction  set.  This 
identifier  is  the  first  data  element  of  the  transaction  set  header 
segment. 

Translation 

The  act  of  accepting  documents  in  other  than  standard  format  and 
translating  them  to  the  standard. 

Version/Release 

Identifies  the  publication  of  the  standard  being  used  for  the  genera¬ 
tion  or  the  interpretation  of  data  in  the  X12  standard  format  May 
be  found  in  the  Functional  Group  Header  Segment  (GS)  and  in  the 
Interchange  Control  Header  Segment  (ISA).  See  Control  Segment. 

Vies  Committee 

Voluntary  Interindustry  Communications  Standards  for  EDI. 

X12 

The  ANSI  committee  responsible  for  the  development  and  main¬ 
tenance  of  standards  for  EDI. 

X12,5 

Interchange  Control  Structure.  This  standard  provides  the  inter¬ 
change  envelope  of  a  header  and  trailer  for  the  electronic  inter¬ 
change  through  a  data  transmission,  and  it  provides  a  structure  to 
acknowledge  the  receipt  and  processing  of  this  envelope. 

X12.6 

Application  Control  Structure.  This  standard  describes  the  control 
segments  used  to  envelop  loops  of  data  segments,  transaction  sets, 
and  groups  of  related  transaction  sets. 
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5.2  DoD  GLOSSARY 

AIS 

Automated  information  systems 
DIISD  (Logistics) 

Deputy  Under  Secretary  of  Defense  (Logistics) 

DES 

Data  encryption  standard 
DISA 

Defense  Information  Systems  Agency 
DLA 

Defense  Logistics  Agency 
ISA 

Interchange  control  header  identifier 
NIST 

National  Institute  of  Standards  and  Technology 
NTE 

Note  identifier 
PLUS 

Protection  of  logistics  unclassified/sensitive  systems 
UN/EDIFACT 

EDIFACT;  electronic  data  interchange  for  administration,  com¬ 
merce,  and  transport 

USD  (A  &  T) 

Under  Secretary  of  Defense  for  Acquisition  and  Technology 
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